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ABSTRACT 


The  objective  of  this  thesis  is  to  explore  uses  of  Internet  technologies  and  business 
model  enhancements  for  Electronic  Systems  Support  Unit  (ESU)  Alameda,  a  small  Coast 
Guard  command.  To  accomphsh  this  task,  this  thesis  will  introduce  the  concept  of  Intranet 
technology,  portray  the  efforts  required  to  create  an  Intranet,  and  then  discuss  the  benefits 
associated  with  Intranet  use. 

The  thesis  introduces  two  popular  design  methodologies,  analyzes  the  advantages 
and  disadvantages  of  each,  and  determines  the  best  Intranet  design  methodology  for  this 
project  by  analyzing  the  needs  and  abilities  of  the  organization.  In  addition,  it  describes  the 
gathering  of  system  and  user  requirements,  data  types,  processes  performed,  business  model 
evaluations,  and  conceptual  Intranet  development. 

The  work  comprised  within  this  thesis  will  enable  coding  and  implementation  of  the 
Intranet  by  another  thesis  team  working  jointly  on  this  project.  While  this  thesis  covers 
details  of  analysis  and  specification  development,  the  thesis  of  the  other  team  will  continue 
discussion  by  addressing  software  coding,  security,  and  maintenance. 
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L  INTRODUCTION 


A.  OBJECTIVE 

This  thesis  describes  the  prototype  intranet  specification  development  for  a  Coast 
Guard  support  command  located  at  Alameda  California.  The  purpose  of  the  prototype 
intranet  development  project  is  to  design  an  effective  business  model  which  will  enable  a 
collaborative  environment  and  enhance  the  use  of  limited  personnel  resources. 

B.  BACKGROUND 

Managing  the  proper  maintenance  and  support  of  all  electronics, 
telecommunications,  and  computer  resources  aboard  all  Coast  Guard  units  located  within 
the  boundaries  of  the  Eleventh  Coast  Guard  District^  is  not  a  trivial  task  for  Electronic 
Systems  Support  Unit  (ESU)  Alameda,  a  small  organization. 

Compounding  these  challenges,  ESU  Alameda^  recently  experienced  two  major 
renovations  that  may  alter  their  business  model  and  existing  culture; 

1.  The  Coast  Guard  used  downsizing  and  streamlining  to  meet  the  budgetary 
reductions  required  by  federal  agencies.  Since  the  Coast  Guard  could  not  reduce  the 
public  services  provided,  several  of  the  Coast  Guard  units  which  previously  supported 
electronics  equipment  were  cut  and  ESU  Alameda  was  tasked  with  covering  the  additional 


^  The  geographic  boundaries  of  the  Eleventh  Coast  Guard  District  refers  to  all  Coast  Guard  resources 
within  the  state  of  California,  and  any  military  vessels  requesting  assistance  in  California  waters. 

^  The  Coast  Guard  uses  four  Electronic  Systems  Support  Units  (ESUs)  on  the  west  coast.  All  are  similar 
and  are  referred  to  by  their  acronym  (ESU),  followed  by  their  location,  (i.e.  ESU  Alameda). 
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workloads.:  As  a  result,  ESU  Alameda  absorbed  a  small  percentage  of  the  previous 
resources  and  a  complete  organizational  restructuring  occurred. 

2.  The  command  completed  a  phased  workstation  migration  from  a  legacy 
proprietary  computer  environment  to  a  new  Windows  NT  networked  platform.  Although 
this  presents  an  enormous  learning  curve  for  ESU  Alameda  employees,  it  offers  the 
command  enormous  opportunities  to  enhance  the  existing  business  model  and  culture  of 
the  command.  Despite  the  continuous  improvements  in  commercial  office  automation,  the 
prior  use  of  proprietary  computers  required  the  generation  of  all  forms  and  reports  to  be 
performed  manually  and  offered  little  to  no  collaboration  between  employees  other  than 
the  use  of  email.  As  a  result,  the  time  spent  performing  routine  administrative  tasks  such 
as  personnel  issues,  the  ordering  and  tracking  of  repair  parts,  and  the  sharing  of 
information  required  extensive  use  of  scarce  personnel  resources. 

C.  PERSONNEL  AND  SUPPLY  TRACKING  DATABASE  SYSTEMS 

These  two  databases  were  specifically  designed  to  reduce  the  command’s  intensive 
time  spent  manually  tracking  both  administrative  and  supply  status  issues.  Working 
conjointly  with  the  intranet  they  will  help  free  up  the  available  time  of  critical  command 
billets  currently  over  tasked  as  a  result  of  the  downsi^g  and  streamlining  initiatives. 

Microsoft  Access  97  was  used  to  build  the  system  under  a  rapid  prototype 
methodology.  The  intranet  functionality  will  then  be  coded  by  another  thesis  student  with 
the  use  of  the  Microsoft  Internet  Information  Server  (IIS)  and  active  server  scripting. 
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D.  CHAPTER  DESCRIPTIONS 

This  section  provides  an  outline  of  the  different  parts  of  this  thesis. 

1.  Chapter  I  Introduction 

This  chapter  provides  a  brief  description  of  the  business  challenges  facing  Coast 
Guard  Electronic  Systems  Support  Unit  (ESU)  Alameda.  The  section  concludes  with  a 
thesis  content  description. 

2.  Chapter  H  Introduction  To  Intranets 

This  chapter  gives  a  foundation  of  intranet  technologies  and  discusses  how 
intranets  are  being  used  to  solve  business  challenges. 

3.  Chapter  HI  Understanding  The  Client’s  Business  Environment 

This  chapter  discusses  the  history,  organization,  and  structure  of  ESU  Alameda 
and  addresses  new  business  requirements  recently  placed  on  the  command  as  a  result  of 
Coast  Guard  restructuring  (Streamlining).  It  addresses  the  current  mission,  goals,  critical 
success  factors  and  processes. 

4.  Chapter  IV  Business  Model  Analysis  &  Design  Plan  Methodology 

Chapter  four  discusses  the  methodologies  used  to  define  ESU  Alameda’s  business 
model  and  explains  how  the  critical  processes  and  requirements  were  defined  for  use  in 
prototype  development. 
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5.  Chapter  V  Candidate  Applications  For  Business  Solutions 

Chapter  five  evaluates  how  different  intranet  applications  could  enhance  ESU 
Alameda’s  mission  effectiveness.  Several  types  of  applications  which  would  significantly 
enhance  the  business  processes  of  the  command  will  be  presented  and  conceptually 
explained.  Although  few  of  the  applications  mentioned  in  this  chapter  will  be  part  of  the 
specifications  development  for  this  project,  this  chapter  offers  ESU  Alameda  potential 
applications  to  consider  for  future  development  efforts.  Mission  urgency  and  customer 
requests  will  dictate  those  used  in  the  prototype  development  and  analyzed  in  proceeding 
chapters. 

6.  Chapter  VI  Analysis  Of  Client’s  Business  Processes 

After  the  interviews  with  ESU  Alameda  were  complete,  the  data  was  analyzed  to 
reveal  possible  ways  the  business  model  could  be  enhanced.  This  chapter  discusses  the 
methodology  used  to  define  the  new  business  model  and  explains  the  use  of  data  flow 
diagrams  in  performing  this  task. 

7.  Chapter  Vn  Rapid  Prototype  Design 

Chapter  seven  discusses  the  rapid  prototype  design  of  the  intranet.  The  use  of 
iterative  database  designs  enabled  a  development  that  met  the  customer’s  needs.  Several 
screen  shots  are  included  to  enable  the  reader  to  understand  the  uses  of  the  database  in  the 
protot5q)e  development  effort. 
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8.  Chapter  Vm  Conclusion 

The  final  chapter  briefly  describes  the  need  for  ESU  Alameda  to  establish  a 
business  policy  for  intranet  use,  and  plan  for  organizational  learning  to  get  the  most  out  of 
an  intranet  system.  Although  intranet  security  is  not  the  focus  of  this  thesis,  a  brief 
security  overview  and  reconunendations  are  provided.  Finally,  as  a  conclusion  to  this 
thesis,  lessons  learned  are  provided  for  future  development  considerations. 
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IL  INTRODUCTION  TO  INTRANETS 


A.  INTRODUCTION 

Chapter  two  will  provide  a  working  background  of  an  intranet  system  and  will 
begin  by  revealing  a  key  reason  why  an  intranet  should  be  considered.  This  chapter  will 
define  the  scope  of  the  intranet  and  will  show  ewdence  of  its  rapid  growth  within  the 
commercial  sector.  In  addition,  a  listing  of  organizational  benefits  will  be  presented.  The 
chapter  continues  by  examining  the  various  technical  parts  that  contribute  to  intranet 
development,  including  a  description  of  the  intranet  structure,  uses  of  web  servers  and 
browsers,  the  client  server  model,  and  intranet  hardware  and  software  requirements. 
Finally,  a  section  of  this  chapter  is  dedicated  to  the  use  of  the  Production  and 
Consumption  Cycle  to  reveal  possible  ways  a  typical  organization  could  gather,  analyze, 
and  share  information  by  using  an  intranet. 


B.  A  TYPICAL  REASON  FOR  AN  INTRANET 


The  Shrinking  Fed^^i  Work  Force 


Federal,  Non-Postal  Employment 
Washington  Metro  Area 


Job  Cat^ories  With  Largest  Reductions  Largest  Job  Reduciioiis  by  Percent  ^ 

'pQi  ai^nctfis.  !vor<i  thun  lO.CCO  ^moioy&es) 


.284.501  269  425 


Accounting 

(3,063) 


Sec  En^neetit^- 


Figure  2.1  The  Shrinking  Federal  Woik  Force,  Ref.  {1] 

The  United  States  government  is  reinventing  the  way  it  operates  in  attempts  to 
balance  the  budget  and  reduce  the  federal  deficit.  To  accomplish  this  task,  the  work  force 
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has  been  reduced  as  illustrated  in  Figure  2.1.  This  reduction  in  force  strength  means  the 

remaining  workers  will  now  have  an  increased  workload  and  must  develop  strategies  for 

coping  with  additional  tasking.  An  Intranet  may  be  the  solution  to  this  cultural  challenge. 

With  the  right  corporate  culture,  intranets  can  become  Uving,  growing, 
organic  ecosystems.  They  promote  learning  and  spawn  the  innovation  that 
allows  organizations  to  do  things  cheaper,  faster,  and  better  [Ref.  2,  p. 
xiii]. 

Use  of  the  intranet  is  not  a  new  concept  and  has  already  been  proven  in  the 

commercial  industry.  The  federal  agencies  which  choose  to  use  this  technology  now,  will 

be  using  a  proven  system  to  conduct  business. 

...the  use  of  intranets  in  the  enterprise  will  grow  110  percent  this  year. 

...15  percent  of  all  Fortune  1000  organizations  will  be  running  intranets  by 
the  end  of  1998.  ...more  than  80  percent  of  Fortune  500  companies 
already  have  some  kind  of  intranet  in  place  [Ref  3,  p.  80]. 

C.  INTRANETS  VERSUS  INTERNETS 

The  internet  and  intranet  are  very  similar  to  each  other  with  both  using  the  same 

type  of  technology.  The  main  difference  between  the  two  is  the  amount  of  privacy  they 
offer.  The  internet  is  a  public  system  while  the  intranet  is  a  small-scale  private  version  of 
the  internet  within  an  organization.  This  private  version  gives  you  a  means  to  collaborate 
with  other  intranet  chents  using  web  browsers  to  instantly  deliver  information  anywhere  in 
your  corporate  network.  Specifically,  the  intranet  offers  a  highly  interoperable,  portable 
cross-platform  system  that  is  extremely  scalable  to  the  expanding  functionality  of  an 
organization.  Both  types  of  systems  use  a  Transmission  Control  Protocol  and  Internet 
Protocol  known  as  TCP/IP.  This  TCP/IP  protocol  is  used  to  carry  packets  of  data  over  a 
network  of  computers.  The  internet  and  intranet  technology  also  uses  World  Wide  Web 
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(WWW)  tools  such  as  Hypertext  Markup  Language  (HTML),  Common  Gateway 

Interface  (CGI)  scripting  languages,  and  Java  and  Active  X  programming  languages. 

All  applications  designed  for  the  Internet  also  run  on  the  Intranet.  From  the 
applications  standpoint,  there  is  no  real  difference  between  these  two  types 
of  networks.  Typical  Intemet/Intranet  applications  include  web,  e-mail, 
newsgroups,  and  file  transfer  (FTP)  [Ref  4]. 

D.  GROWTH  OF  INTRANETS 

The  tools  and  capabilities  that  made  the  internet  such  a  huge  success  are  now 
letting  thousands  of  companies  share  information  inside  their  own  organization.  The 
grotYth  of  the  internet  and  intranet  is  spectacular.  The  graph  in  Figure  2-2  is  a  single  graph 
which  includes  everything  related  to  the  intranet  including  such  things  as  growth  in  domain 
numbers,  users,  and  access  providers.  The  x-axis  lists  the  years  from  1990  to  1995  and 
estimates  for  1996  to  1998.  The  y-axis  reveals  the  amount  of  growth. 


Figure  2.2  Growth  Of  The  Internet,  [Ref.  2,  p.  7] 
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Ian  Campbell,  Director  of  Collaborative  Technologies  for  International 
Data  Corporation  (EDC),  estimates  that  there  were  100,000  intranet  web 
servers  in  1995,  and  that  this  number  will  grow  to  4.7  million  by  the  year 
2000.  He  also  said  that  there  were  approximately  10  million  Web  browsers 
in  use  in  1995,  and  he  estimates  that  number  will  be  40  million  in  1996  and 
180  million  in  the  year  2000.  By  any  yardstick,  that  is  phenomenal  growth 
[Ref  2,  p.  8]. 

There  are  several  different  classifications  of  intranets  with  each  being  specified  by 
the  function  of  their  use. 

The  Gartner  Group  classifies  intranet  proliferation  and  development  into 
three  levels.  Level  1  intranets  consist  of  low-level  implementations,  static 
publishing  ,  or  simply  moving  content  on-line.  Level  n  intranet 
development  centers  around  enabling  core  day-to-day  applications  for  web 
use  and  using  the  intranet  as  a  workgroup  computing  platform.  Level  HI 
intranets  wiU  be  characterized  by  a  large  base  of  web-enabled  applications, 
a  consolidation  of  dozens  of  Application  Program  Interfaces  (API’s)  used 
in  Level  H,  more  secure  web  servers,  and  more  powerful  development 
tools.  Most  companies  spent  1996  testing  intranet  waters  at  level  I. 
Mainstream  organizations  are  expected  to  develop  Level  11  intranets  in 
1997  and  1998.  By  1999,  top  organizations  are  expected  to  plateau  at 
Level  in  [Ref  3,  p.  80-81]. 


E.  USES  OF  EXTRANETS 

Once  the  intranet  is  established  in  a  corporation  the  uses  are  almost  endless  and  are 
largely  dictated  by  the  imagination  of  the  designer  and  administrator.  Many  of  the  roles 
the  intranet  plays  are  very  simple,  requiring  simple  web  pages  created  using  HTML. 
Others  can  become  extremely  complex  and  sophisticated  requiring  special  programming 
and  links  to  developed  databases.  Figure  2.3  gives  a  graphical  breakdown  of  ways 
corporations  are  currently  using  intranet  technology. 
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How  Intranets  Are  Being  Used 


a> 

S 


0) 

Q. 


®  Access  to  manuals  and 
procedures 

■  Post  personal  web  pages 

□  Access  product  and 
marketing  data 

□  post  internal  job  offerings 

■  Rivise  and  approve 
documents 

@  Access  employee 
information 

■  Schedules,  calendars, 
timelines 

0  Access  existing  databases 


Figure  2.3  How  Intranets  Are  Being  Used,  [Ref.  5,  p.  15] 


Here  are  a  few  examples  of  what 
pp.  8-9], 

♦  Electronic  Mail 

♦  Directories 

♦  Organization  charts 

♦  Memos 

♦  Personnel  manuals 

♦  Benefits  information 

♦  Newsletters  and  pubhcations 

♦  Systems  user  documentation 

♦  Training 

♦  Newsgroups 

♦  New  extracts 

♦  Job  postings 

♦  Sales  reports 

♦  Financial  reports 


may  be  found  on  a  typical  intranet  [Ref  2, 


♦  Customer  information 

♦  Quality  statistics 

♦  Vendor  information 

♦  Product  information 

♦  Marketing  brochures,  videos, 
presentations 

♦  Product  development 
information  and  drawings 

♦  Inventory  information 

♦  Network  management 

♦  Asset  management 

♦  Supply  and  component 
catalogs 
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F.  THE  ADVANTAGES  OF  INTRANETS 


There  are  numerous  reasons  an  organization  may  want  to  set  up  an  intranet.  Here 
are  just  a  few  of  the  possible  reasons: 


1.  Tangible  benefits  of  intranets  [Ref.  2,  p.  29] 


♦  Fast  and  easy  to  implement 

♦  Cheap  to  implement 

♦  Easy  to  use 

♦  Save  Time 

♦  Provide  operational  ejBBciency 

♦  Save  cost 

♦  Based  on  open  standards 

♦  Connect  and  communicate 
among  disparate  platforms 


♦  Put  users  in  control  of  their 
data 

♦  Secure 

♦  Scalable 

♦  Flexible 

♦  Provide  the  richness  of 
multimedia 

♦  Leverage  your  infrastructure 
and  applications  investment 


2.  Intangible  benefits  of  intranets  [Ref.  2,  pp.  29-30] 


♦  Provide  better  communication 

♦  Provide  access  to  accurate 
information 

♦  Capture  and  share  knowledge 
and  expertise 

♦  Provide  better  coordination 
and  collaboration 


♦  Provide  for  creativity  and 
innovation 

♦  Provide  new  business 

opportunities 

♦  Provide  new  business 

partnerships  through  access 
by  suppliers  and  customers 


Intranets  are  relatively  inexpensive  to  install  and  administer  compared  to  other 
forms  of  group  collaboration  techniques  such  as  long  distance  phone  calls, 
teleconferencing,  meetings,  and  some  GroupWare  products.  Web  browsers  are  available 
from  several  sources  either  for  free  or  for  a  modest  price,  and  many  of  the  web  servers 
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required  are  packaged  with  operating  systems  which  may  already  be  in  place.  An  example 

of  such  an  operating  system  is  Microsoft’s  Windows  NT  Server.  Whereas  many 

GroupWare  products  (unlike  the  intranet)  are  not  fully  interoperable  and  requires  specific 

hardware,  operating  system,  and  network  configuration  [Ref  6].  A  new  study  conducted 

by  U.S.  Computer  and  funded  by  Sun’s  Internet  Commerce  Group  indicates  that  web 

technologies  can  reduce  internal  corporate  networking  costs  by  as  much  as  $11  million 

over  four  years  for  a  large  network  [Ref  7]. 

The  intranet  operates  on  an  open  platform  meaning  that  it  acts  as  its  own  layer, 

independent  of  the  operating  system.  There  is  no  need  to  change  the  existing  hardware  or 

operating  system  already  in  place.  If  it  is  a  standard  system,  then  there  will  most  likely  be 

a  browser  available  for  it,  making  it  intranet  capable. 

The  one  hidden  expense  of  setting  up  a  corporate  intranet  is  that  you  must 
run  TCP/IP  (transmission  control  protocol/Intemet  Protocol),  the 
protocols  that  define  how  information  is  passed  around  the  internet,  on 
your  network.  If  your  organization  runs  on  TCP/IP  now,  then  you’ve  paid 
the  price  for  more  memory  and  new  software  in  desktop  PCs  and  more 
capable  routers  throughout  the  network  [Ref  8,  p.  107]. 

G.  INTRANET  COMPONENTS 

Each  organization  will  set  up  an  intranet  differently.  Some  will  consider  the  inside 
use  of  the  web  along,  along  with  any  specific  web  based  apphcations,  as  their  intranet. 
While  others  will  also  consider  the  actual  computer  network  of  the  organization  as  part  of 
the  network.  Here  are  some  of  the  most  common  components  of  an  intranet:  [Ref  2, 
pp.  9-10] 
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♦  Network 

♦  Electronic  Mail 

♦  Internal  web 

♦  Newsgroups 

1.  Network 


♦  Chat 

♦  FTP 

♦  Gopher 

♦  Telnet 


The  first,  and  most  complicated,  part  of  any  intranet  is  the  network.  The 
intranet  is  the  network  of  many  networks.  In  large  organizations,  the 
intranet  may  also  be  a  network  of  networks.  In  smaller  organizations,  it 
may  be  just  a  singe  network.  At  any  rate,  the  network  is  at  the  heart  of  the 
intranet.  The  intranet  can’t  exist  without  it  [Ref  2,  p.  10], 


Organizations  can  use  a  variety  of  different  technologies  the  link  their  computers 
together  to  form  networks.  The  main  design  factors  would  consider  such  things  as 
funding  requirements,  distances  between  computers,  use  of  existing  computer  hardware, 
and  the  amount  of  security  an  organization  requires.  A  simple  type  of  network  is  a  Local 
Area  Network  (LAN).  A  LAN  serves  only  a  single  group  of  users  within  the  same 
physical  space.  Examples  of  a  LAN  would  be  a  military  command  inside  the  same 
building,  or  a  department  within  an  organization.  As  previously  mentioned,  LANs  can  be 
made  up  of  varying  types  of  technologies.  Ethernet,  Token  Ring,  and  Fiber  Distributed 
Data  Interface  (FDDI)  are  among  the  most  common.  A  description  of  each  follows: 


Network  Types 

♦  Ethernet.  Ethernet  LANs  consist  of  coaxial  cables  or  twisted-pair  (standard 
telephone)  wire  hooked  to  a  device  called  a  hub.  The  hub  is  the  traffic  cop 
that  directs  traffic  along  the  network 

♦  Token  Ring.  Token  Ring  LANs  consists  of  coaxial  cables  or  twisted-pair 
wires  attached  into  a  Media  Attachment  Unit  (MAU).  The  MAU  simulates  all 
devices  being  cormected  into  a  ring.  Computers  on  the  ring  take  turns 
transmitting.  A  token  passes  sequentially  to  each  device  on  the  ring  to  indicate 
when  it  is  their  turn  to  transmit. 
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♦  FDDI.  FDDI  networks  are  similar  to  Token  Ring  Networks  in  that  they  also 
pass  a  token.  However,  they  use  fiber-optic  cable  instead  of  twisted-pair  wires 
[Ref  2,  p.  10], 

2.  Electronic  Mafl 

Electronic  Mail,  otherwise  referred  to  as  e-mail,  allows  one  person  to  compose  a 
message  and  send  it  electronically  to  anyone  in  the  world  who  has  an  e-mail  address 
established.  The  receiver  can  also  respond  just  as  easily.  With  the  improving  of  email 
software  programs,  email  is  no  longer  limited  to  just  text  files.  Users  can  now  send 
formatted  documents,  presentations,  sound  files,  and  video  cKps  just  as  easily  as  a  text 
document. 

By  default,  e-mail  is  generally  an  organizations  first  intranet  application.  It 
provides  the  opportunity  to  communicate  from  one  person  to  another  or  to  many  people 
[Ref  2,  p.  11]. 

3.  Internal  Web 

When  people  think  about  internets  they  are  usually  thinking  about  internal  webs, 

however,  the  internal  web  is  not  synonymous  with  an  intranet.  It  is  only  a  part  of  it,  but  it 

is  a  very  important  part.  Just  like  the  use  of  e-mail  and  web  browsers  have  caused  the 

internet  to  explode,  they  have  done  the  same  for  the  intranet. 

The  internal  web  is  simply  using  Web  tools  inside  your  organization.  It 
makes  your  corporate  information  easy  to  access.  All  users  have  to  know 
is  how  to  use  a  mouse  to  point  and  click.  If  they  can  do  that,  then  any 
information  they  need  can  be  available  at  their  fingertips.  With  the  addition 
of  search  tools  to  the  interaal  web,  if  they  can  use  a  keyboard,  the 
possibilities  become  almost  endless  [Ref  2,  p.  12]. 
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The  use  of  the  internal  web  will  allow  different  divisions  of  an  organization,  or 
different  teams  within  a  division  to  collaborate  and  share  information.  This  works 
differently  than  a  typical  network.  For  instance,  a  maintenance  team  may  require  logistics 
information  from  an  unavailable  supply  division.  Under  a  network  system  they  would 
have  to  know  exactly  where  the  information  was  stored,  and  then  possess  the  exact 
application  required  to  view  the  data  at  their  computer.  Under  an  intranet,  a  search  for  a 
key  word  could  be  performed  to  find  the  needed  file,  and  then  that  file  viewed.  This  is 
because  the  internal  web  is  not  application  dependant.  This  example  of  course  assumes 
the  security  of  the  file  allows  access. 

The  internal  web  consist  of  two  major  components. 

1.  Web  Server 

2.  Web  Browser 

a.  Web  Server 

The  web  servers  act  as  the  hub  for  the  entire  intranet.  They  are  computers 
which  store  all  the  web  pages  and  use  the  H5q)ertext  Transfer  Protocol  (HTTP)  to  send 
the  needed  page  to  a  web  browser  (or  client)  when  requested. 

b.  Web  Browser 

The  primary  function  of  the  web  browser  is  to  act  as  a  graphical  user  interface 
(GUI)  between  the  user  and  the  web  server.  For  this  reason,  the  web  browser  is  also 
referred  to  as  a  client  of  the  web  server.  More  on  this  type  of  relationship  will  be 
explained  later  in  this  chapter.  The  browser  portion  of  the  internal  web  is  physically 
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located  on  the  user’s  computer.  The  user  uses  the  browser  to  request  pages  from  the  web 
server  and  download  Hypertext  Markup  Language  (HTML)  documents.  As  web 
browsers  have  become  more  robust  in  their  operation,  they  have  mirrored  themselves  to 
work  with  other  internet  software  tools  within  the  same  browser  program.  Examples  of 
other  internet  related  functions  include  e-mail,  newsgroups,  and  File  Transfer  Protocol 
(^P).  The  browser  is  a  critical  part  of  the  intranet  because  it  enables  a  common  interface 
between  all  users  and  their  shared  information.  With  a  browser  on  every  computer,  users 
are  no  longer  required  to  have  the  same  applications  as  a  different  department  to  view  data 
files.  The  savings  in  software  purchasing  alone  could  become  enormous  as  long  as  the 
original  data  is  saved  in  the  HTML  format. 

4.  Newsgroups 

Using  a  newsgroup  with  a  web  browser  is  similar  to  using  email.  The  difference 
being  that  the  information  is  published  so  everyone  accessing  the  newsgroup  can  read  the 
ongoing  content  instead  of  just  a  selected  few.  This  form  of  communications  also  reduces 
the  congestion  of  hardware  resources  since  a  user  checks  a  newsgroup  instead  of  everyone 
being  sent  the  same  email.  This  type  of  collaboration  enables  threaded  discussion 
(continued  discussions)  where  different  people  can  ask  questions  or  discuss  topics  of 
common  interests.  It  also  allows  archiving  of  discussions  where  search  mechanisms  can 
be  used  to  seek  out  answers  to  previously  answered  questions.  Acting  in  a  sense  as  a 
knowledge  base  for  corporate  information. 
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5. 


Chat 


Internet  Relay  Chat  (IRC)  facilitates  conversations  over  the  internet  in 
close  to  real  time.  On  an  intranet,  chats  can  take  the  place  of  long-distance 
phone  calls  between  locations.  They  allow  you  to  communicate  ideas  more 
quickly  than  through  e-mail.  Chats  facilitate  brainstorming  sessions  for 
participants  who  can  convene  at  the  same  time,  but  not  at  the  same  place. 

You  can  schedule  a  chat  about  any  topic  of  common  interest  and  anyone 
can  participate.  You  can  also  use  chat  for  impromptu  conversations  [Ref 
2,p.  19], 

6.  FTP 

File  transfer  protocol  (FTP)  provides  you  a  repository  of  information  that 
is  readily  accessible.  Anyone  with  FTP  can  log  in  to  the  repository  and 
download  what  they  need  to  their  computer.  FTP  works  well  for 
transferring  files  that  are  too  large  to  send  by  e-mail  [Ref  2,  pp.  19-20]. 

A  few  ways  FTP  can  be  used  on  an  intranet  are: 

♦  Allow  users  to  download  software  and  patches 

♦  Allow  web  pages  to  be  uploaded  to  servers 

♦  Permit  file  transfers  of  very  large  files  such  as  drawings,  project  drawings  and 
specifications  and  computer  aided  design  files 


7.  Gopher 

Like  much  of  the  internet,  gopher  provides  text-only  information.  Gopher 
is  menu-driven,  making  it  easy  for  you  to  drill  down  through  levels  of 
menus  to  get  to  the  information  you  need.  Before  the  advent  of  the  Web, 
gopher  servers  provided  the  richest  repositories  of  information  on  the 
internet  [Ref  2,  p.  20], 

Just  like  FTP  applications  are  now  part  of  the  typical  browser,  gopher 
applications  have  also  joined  the  browser  role.  To  a  large  extent,  the  web  has 
replaced  the  typical  gopher  servers  previously  used,  but  there  may  still  be  archived 
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information  on  gopher  servers  that  could  benefit  an  organizations  intranet  design. 
If  an  organization  needs  access  to  these  large  collections  of  government  and 
university  gopher  servers  or  if  the  organization  already  is  using  a  gopher  server, 
then  a  gopher  server  is  probably  not  needed  on  the  modem  intranet. 


8.  Telnet 

Telnet  allows  you  to  log  in  to  a  remote  computer.  It  typically  provides 
access  to  resources  that  reside  on  remote  mainframes.  Telnet  (TN)  3270 
allows  you  to  access  a  mainframe  and  emulate  a  3270  host-based  terminal. 
A  major  use  for  TN3270  is  to  provide  access  to  university  library  card 
catalogs  and  databases.  You  can  use  it  to  open  up  your  mainframe 
applications  to  your  intranet;  however,  it’s  not  as  pretty  as  using  the  Web 
[Ref  2,  p.  20]. 


H.  INTRANET  TECEINOLOGIES 


1.  The  Client/server  Model 

To  understand  how  the  internet  and  intranet  operates,  it  is  important  to  understand 
the  concept  of  client/server  computing.  The  client  server  model  as  shown  in  Figure  2.4  is 
a  form  of  distributed  computing  where  one  application  (the  client)  communicates  with 
another  application  (the  server)  for  the  purpose  of  exchanging  information.  Specifically 
the  client  and  server  perform  the  following  functions  [Ref  9]: 


a.  The  client’s  responsibility  is  usually  to: 

♦  Handle  the  user  interface. 

♦  Translate  the  user's  request  into  the  desired  protocol. 

♦  Sends  the  user  request  to  the  server. 

♦  Waits  for  the  server's  response. 

♦  Translate  the  response  into  "human-readable"  results. 


19 


♦  Present  the  results  to  the  user. 


b.  The  server's  functions  include: 

♦  Listen  for  a  client's  query. 

♦  Process  that  query. 

♦  Return  the  results  back  to  the  client. 


Web  Server  Web  client  (browser) 


Figure  2.4  Client  Server  Dialog  [Ref.  10,  p.  8] 


Referencing  Figure  2.4  for  this  example,  a  person  uses  the  browser  as  their  primary 
interface  to  interact  with  the  application  they  desire.  In  this  case,  a  user  will  run  client 
software  to  create  a  query.  The  client  then  connects  to  the  server  in  a  method  transparent 
to  the  user.  The  browser  uses  interpreters  to  interact  with  the  intemet/intranet  resources 
to  access  the  information  desired  by  the  user.  Both  sides  use  URLs  to  describe  the 
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protocols  and  locations  of  web  resources  without  regard  to  the  particular  client  software 
the  user  is  employing  to  access  them  [Ref  1 1],  Using  standard  protocols  the  client  sends 
the  query  to  the  server  where  the  server  analyzes  it,  computes  the  results  of  the  query  and 
then  sends  the  results  back  to  the  client  using  established  internet  protocols.  The  server 
may  also  use  other  sever  based  programs  to  obtain  the  results,  which  are  then  sent  to  the 
client  is  similar  fashion.  Once  received,  the  client  presents  the  results  to  the  user  in  the 
browsers  graphical  interface.  Similar  process  occurs  for  many  of  the  other  chent  server 
interactions. 

Key  WWW  specifications  include  the  Hypertext  Markup  Language  (HTML), 
Uniform  Resource  Locators  (URLs),  Multipurpose  Internet  Mail  Extension  (MIME  and 
the  Hypertext  Transfer  Protocol  (HTTP)  [Ref  10,  pp.  8-9].  These  specifications  are 
discussed  as  follows: 

♦  Hypertext  Markup  Language  (HTML)  -  HTML  is  used  when 
publishing  a  document  that  is  to  be  displayed  through  the  WWW. 

HTML  is  a  set  of  simple  syntax  commands  that  describes  how  a 
document  is  structured.  This  language  allows  the  user  to  define  the 
parts  of  a  document,  but  not  the  formatting,  so  that  the  browser  used 
for  reading  the  document  can  format  it  best  to  suit  the  user’s  display. 

♦  Uniform  Resource  Locators  (URLs)  -  a  URL  is  a  complete 
description  of  an  item,  containing  the  location  of  the  item  you  want  to 
retrieve.  A  typical  URL  looks  like  this:  http://www.nps.navv.mil.  the 
first  item  in  the  URL  (portion  that  ends  with  a  colon)  is  the  protocol 
used  to  retrieve  the  item.  For  this  URL  the  protocol  is  Hypertext 
Transfer  Protocol.  The  two  forward  slashes  that  follow  indicate  that 
what  follows  is  a  valid  host  address.  It  can  either  be  the  text  as  shown 
or  the  actual  corresponding  IP  address  of  the  site. 

♦  Multipurpose  Internet  Mail  Extension  (MIME)  -  MIME  is  an 
extension  to  the  existing  Simple  Mail  Transport  Protocol  (SMTP) 
standards  that  offer  a  standardized  way  to  represent  and  encode  a  wide 
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variety  of  media  types,  including  textual  data  in  non-ASCI  character 
sets,  for  transmission  via  internet  mail. 

♦  Hypertext  Transfer  Protocol  (HTTP)  -  After  it  was  decided  to  use 
hypertext  as  the  standard  format  for  WWW  documents,  a  protocol  that 
allowed  these  hypertext  documents  to  be  retrieved  quickly  was 
developed.  This  protocol  is  HTTP.  HTTP  is  a  fairly  simple 
communication  protocol  that  allows  the  document  it  is  retrieving  to 
retain  hyperlinks  to  other  documents  during  download  [Ref  12,  pp. 
117-140]. 


1.  HARDWARE  AND  SOFTWARE  REQUIREMENTS 

A  computer  system  operating  on  an  open  system  TCP/IP  network  can  also  run 

internal  applications  distributed  over  a  corporate  LAN  by  using  an  intranet.  This  is 
accomplished  in  a  similar  fashion  that  the  internet  uses  web  servers  and  browsers. 
Because  the  protocols  used  within  the  intranet  are  optimized  for  the  low-bandwidth 
modem  connections  typically  found  in  the  internet  environment,  the  intranet  does  not 
demand  high  speeds  fi-om  any  of  its  hardware  components.  Even  though  the  intranet  web 
server  and  browser  form  the  heart  of  the  intranet,  it  cannot  exist  without  an  existing 
computer  network  infrastructure  in  place.  This  infrastructure  will  have  it’s  own  hardware 
and  software  requirements  and  will  largely  dictate  the  amount  of  CPU,  RAM,  and  Disk 
Storage  resources  the  system  will  require.  Typical  requirements  to  consider  include; 
Requirements: 

♦  server  machines  and  client  workstations,  which  can  include  a  mix  of 
platforms  (such  as  versions  of  Unix,  Windows,  and  Macintosh), 
applications,  and  network  services,  all  communicating  via  the  TCP/IP 
protocol 
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♦  network  backbone  (LANAVAN),  consisting  of  connections,  cables, 
satellite  links,  bridges,  routers,  brouters,  repeaters,  and  other 
components  (Optional)  backend  databases,  which  can  include  a  mix  of 
legacy  databases,  departmental  databases,  data  warehouses,  and  other 
data  stores 

♦  Standard  TCP/DP  services,  including  Hypertext  Transport  Protocol 
(HTTP),  Domain  Name  Service  (DNS),  File  Transport  Protocol  (FTP), 
GopherS,  Usenet  news,  Wide  Area  Information  Servers  (WAIS's), 
remote  login  services  (Telnet),  electronic  messaging,  and  so  on, 
running  on  server  and  client  machines 

♦  All  network  resources  are  configured  with  IP  addresses  and 
communicate  with  other  resources  via  TCP/IP.  The  network  may  be 
distributed  across  multiple  sites.  Information  access  is  controlled  via 
user  authentication,  firewalls,  certificates,  the  Secure  Sockets  Layer 
(SSL),  and  other  mechanisms 

♦  To  deploy  an  intranet,  your  organization  must  have  a  fully  operational 
TCP/IP  network  installed  either  throughout  the  enterprise  or  in  the 
portion  of  the  LAN/WAN  on  which  you  want  to  run  your  intranet 
applications  [Ref  13]. 

♦  Web  authoring  software  to  create  and  update  site  content. 

Although  the  functional  design  of  the  network  will  dictate  the  majority  of  the 
hardware  requirements  for  the  intranet,  there  is  a  large  degree  of  flexibility  in  choosing  the 
software  applications,  servers,  browsers,  and  scripting  languages  used.  The  designs  of 
intranets,  along  with  their  software  requirements,  can  vary  in  complexity  depending  on  the 
design  objectives  of  the  intranet.  On  the  simple  side,  static  web  pages  are  posted  using 
easy  to  use  office  software  such  as  word  processors.  On  the  complex  side,  information 
requires  large  streaming  multimedia  files,  database  and  application  interactions,  and  use  of 
Common  Gateway  Interface  (CGI)  programs  to  meet  desired  organizational  functionahty. 
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Once  the  objective  of  the  intranet  is  established  by  the  organization,  the  choice  of 
web  server  must  be  determined.  Since  web  servers  are  continually  emerging,  each  must  be 
evaluated  on  flexibility,  cost,  and  ease  of  use.  Currently,  Netscape  FastTrack  Server  is  the 
best  bet  for  a  no-frills  server.  Netscape  Enterprise  Server  and  Microsoft  Internet 
Information  Server  (free  with  NT  4.0  server)  are  more  industrial  strength.  They  each 
contain  security  features,  search  engines,  and  ability  to  interact  with  databases.  A  second 
choice  that  must  be  made  is  the  way  the  intranet  web  will  be  developed.  Choices  include 
programming  in  HTML,  or  use  of  many  WYSIWYG  editors  that  help  develop  the  HTML 
code  such  as  HotDog,  FrontPage,  and  NetObjects  Fusion.  If  the  intranet  involves 
interactions  with  databases  then  a  Common  Gateway  Interface  (CGI)  program  will  be 
required  for  the  database  and  web  server  to  interact  with  each  other.  Common  CGI 
programs  include  Cold  Fusion,  and  Microsoft  Active  Server  Pages  [Ref  14].  Several 
elements  determine  which  applications  are  best  suited  for  the  intranet  design  including 
budget,  available  time,  developer  skills,  prior  experiences,  technical  support,  release  dates, 
and  current  product  reviews. 

J.  INFORMATION  CREATION  AND  CONSUMPTION 

...most  users  on  intranets  are  not  "webmasters",  but  rather  business  users 
who  need  to  create  and  analyze  information.  Presentation  is  important  but 
secondary.  Their  goal  is  to  get  their  job  done  [Ref  15,  p.  1]. 

An  intranet  offers  little  value  to  an  organization  if  the  consumption  and 

distribution  of  data  does  not  support  the  operational  environment.  For  the  most 

part,  organizations  access  data,  collaborate  information,  publish  results  and 
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generate  memos,  proposals,  budgets,  analysis,  presentations,  and  supporting 
documentation. 

To  take  advantage  of  the  new  opportunities  an  intranet  can  ofiFer  an 
organization  it  must  be  willing  to  allow  cultural  change  of  the  employees. 
However,  there  is  a  distinct  danger  that  this  change  could  pursue  the  adaptation  of 
time  consuming  graphical  displays  instead  of  the  creative  collaboration  of  ideas  if 
not  properly  managed.  For  this  reason,  adequate  training  in  web  publication  and 
standards  of  content  will  be  required.  To  maintain  organizational  unity  guidelines 
can  be  established,  but  the  enforcement  and  creativity  of  intranet  use  should  be 
decentralized  to  each  division  to  enhance  individual  productivity  and  effectiveness 
of  the  intranet.  With  different  operational  roles,  each  division  will  different  ways 
to  use  the  intranet  resources  to  save  time  and  maximize  creativity  among  peers. 
Figure  2.5  introduces  the  information  development  and  consumption  cycle  which 
focuses  on  the  concept  of  developing  relevant  up  to  date  iirformation. 


25 


AnaiyzeXCreate 

Figure  2.5 

Information  Production  and  Consumption  Cycle,  [Ref.  15,  p.  3]. 

The  process  starts  with  an  organizational  member  having  a  need  for 
information. 

The  t3^ical  knowledge  worker  operates  in  the  context  of  the  information 
creation  and  consumption  process.  Their  primary  product  is  new 
information  which  contributes  to  the  collective  corporate  knowledge  base 
of  information.  For  example,  a  knowledge  worker  gathers  information  from 
many  sources,  perhaps  from  the  Internet,  corporate  databases  or  a  Word 
document  on  the  LAN.  As  this  information  is  collected  and  analyzed,  the 
user  begins  to  create  new  content  using  familiar  tools  like  Microsoft  Office. 

In  some  this  creation  process  involves  several  people  and  content  is 
developed  coUaboratively.  Once  this  information  is  distributed  others  can 
access  it  and  use  it  to  drive  other  cycles  of  information  consumption  and 
creation  [Ref  15,  p.  3]. 

The  first  step  in  the  circular  data  generation  process  is  to  gather  up  to  date  and 
valid  content  pertaining  to  specific  organizational  requirements.  Once  sufficient  content  is 
collected  the  second  stage  begins.  In  the  second  stage  the  content  is  analyzed,  clarified, 
and  composed.  Web  based  applications  are  used  to  create  HTML  documents  capable  of 
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bringing  out  the  key  concepts  of  the  collected  data  so  other  members  of  the  group  can 
quickly  gain  the  obtained  knowledge  base  of  new  information.  Finally,  the  third  and  final 
stage  occurs  where  the  data  is  published  and  collaborated  among  the  various  users  within 
the  organization  to  enhance  team  productivity.  The  iterative  process  creates  and  maintains 
an  organizational  knowledge  base  of  relevant  and  timely  data.  As  organizations  develop 
their  intranets  they  continue  to  learn  and  will  select  the  specific  publishing  technology  that 
best  addresses  their  needs. 

K.  CONCLUSION 

This  chapter  spanned  a  wide  area  of  topics  including  reasons  a  government 
organization  may  consider  developing  an  intranet,  a  background  description  of  what  an 
intranet  is  and  how  rapidly  it  has  grown  within  the  commercial  sector.  The  chapter 
continued  by  defining  numerous  uses  of  an  intranet  and  then  defined  several  tangible  and 
intangible  benefits  to  using  an  intranet  technology.  It  looked  at  the  various  technical 
pieces  of  an  intranet  and  explained  their  purpose  within  the  intranet  structure.  The  chapter 
continued  providing  background  material  by  oflfering  a  description  of  the  basic  concept  of 
web  servers  and  the  use  of  browser  within  a  distributed  client  server  model,  explaining 
how  their  functions  enable  the  sharing  of  intranet  resources.  Intranet  development 
planning  was  introduced  along  with  considerations  to  be  made  in  estabhshing  hardware 
and  software  requirements.  The  chapter  concluded  by  discussing  ways  a  typical 
organization  would  gather,  analyze,  and  publish  information  using  the  Information 
Production  and  Consumption  Cycle  to  improve  an  organizations  knowledge  base  of  up  to 
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date  relevant  information.  The  following  chapter  focuses  on  the  mission  of  the  Coast 
Guard’s  Electronics  Systems  Support  Unit  (ESU)  Alameda,  located  in  Alameda 
California. 
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m.  THE  CUSTOMER 


A.  INTRODUCTION 

The  ability  to  use  the  concept  of  database  design  and  internet  active  server 
scripting  intrinsically  motivated  two  separate  thesis  teams  to  work  together  as  a  design 
team  and  develop  a  prototype  intranet  for  a  receptive  organization.  The  search  for  such 
an  organization  was  limited  to  those  willing  to  share  their  existing  business  challenges  with 
the  team,  and  to  those  who  already  possessed  or  would  soon  possess  a  technical 
architecture  sufficient  for  intranet  development.  Ideally,  the  organization  would  be  able  to 
specifically  identify  and  be  in  control  of  their  critical  requirements,  be  under  extrinsic 
motivation  to  change  existing  business  routines,  and  be  extremely  willing  to  discuss  ways 
their  business  model  could  change  to  improve  operational  performance. 

This  chapter  focuses  on  Electronic  System  Support  Unit  (ESU)  Alameda,  which  is 
a  small  Coast  Guard  command  located  in  Alameda  California.  A  brief  history  of  the  unit  is 
provided,  followed  by  a  review  of  the  command’s  functional  organization,  and  mission 
objectives.  Finally,  those  forces  extrinsically  motivating  the  need  for  internal  change  will 
be  introduced  along  with  the  command’s  requests  for  the  team. 

B.  BACKGROUND 

1.  Agency  Overview 

The  Coast  Guard  is  the  primary  federal  agency  with  maritime  authority  for 
the  United  States.  It  is  a  complex  organization  of  ships,  aircraft,  boats  and 
shore  stations.  Decentralized,  both  administratively  and  operationally,  CG 
personnel  respond  to  tasks  in  several  mission/program  areas.  A  vessel  may 
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carry  out  roles  in  law  enforcement,  search  and  rescue,  marine 
environmental  protection,  maintenance  of  aids  to  navigation,  and  ice 
breaking.  An  aircraft  may  search  for  and  assist  distressed  vessels,  evacuate 
injured  people,  conduct  pollution  detection  and  surveillance  flights,  report 
sightings  in  conjunction  with  law  enforcement,  and  carries  out  the  mission 
of  the  International  Ice  Patrol  [Ref  16], 

The  Coast  Guard  forms  a  hierarchical  organization  which  is  geographically 
separated  into  two  (west  coast  and  east  coast)  similar  platforms.  Acting  within  the 
Commandant’s  guidelines,  the  Atlantic  Area  and  Pacific  Area  Commanders  cany  out  the 
missions  of  the  Coast  Guard  by  directing  each  of  their  respective  district  admirals.  Each 
of  the  several  district  admirals  then  uses  their  numerous  commanding  officers  and 
operational  platforms  to  actually  carry  out  the  missions  of  the  Coast  Guard.  When 
technical  problems  arise,  operational  support  is  received  from  the  respective  Maintenance 
and  Logistics  Command  (MLC  Atlantic  or  MLC  Pacific).  To  enhance  the  support 
capabilities  of  the  single  Maintenance  and  Logistics  Command,  specialized  functional 
support  commands  are  decentralized  and  geographically  located  in  each  district.  Since 
there  are  several  operational  platforms  scattered  throughout  each  district,  the  support 
commands  may  further  decentralize  their  techmcal  staffs  to  increase  effectiveness.  As 
previously  mentioned,  the  west  coast  Maintenance  and  Logistics  Command  uses  four 
Electronic  Systems  Support  Units  (ESUs)  to  directly  support  the  Pacific  Area 
(PACAREA)  Commander  and  four  district  admirals.  Each  ESU  provides  a  similar  role 
within  their  respective  geographical  boundaries  and  operates  under  the  supervision  of  the 
MLCPAC  Electronics  Systems  Division  (t).  Figure  3.1  provides  the  Coast  Guard’s 
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hierarchical  organization  down  to  the  Area,  District,  and  MLC  levels.  The  ESU  is 
conceptually  part  of  the  MLC  unit  within  this  diagram. 


2.  Mission 

The  mission  of  Electronics  Support  Unit  (ESU)  Alameda  is  to  provide  complete 
and  timely  electronics,  telecommunications,  and  computer  related  support  to  any  Coast 
Guard  unit  operating  within  the  geographical  boundaries  of  the  Eleventh  Coast  Guard 
District!  Figure  3.2  portrays  the  area  of  responsibility  and  gives  a  good 

!  The  boundaries  of  the  Eleventh  Coast  Guard  District  encompass  the  states  of  California,  Nevada,  Utah, 
and  Arizona. 
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Figure  3.2  ESU  Area  Of  Responsibility,  [Ref.  18]. 
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In  addition  to  the  units  provided  in  Figure  3.2,  ESU  Alameda  is  also  responsible 
for  supporting  all  Coast  Guard  cutters  transiting  the  waters  of  the  Eleventh  Coast  Guard 
District. 

The  scope  of  this  technical  support  includes  the  provisions  of  timely  maintenance, 
repair,  and  any  form  of  technical  assistance  requested  from  an  operational  unit  including 
technical  advice.  These  tasks  are  accomplished  by  providing  the  following  services  under 
the  authority  of  the  Maintenance  and  Logistics  Pacific  instructions,  specifically 
MLCPACINST  10550.1  (series): 

Contract  Support 

The  Eleventh  Coast  Guard  District  (Dll)  Maintenance  Contract  is  the  primary 
means  of  providing  preventative  and  corrective  electronics  maintenance  to  Groups,  Air 
Stations,  Patrol  Boats  (WPBs)  and  Stations  within  Dll.  ESU  Alameda  administers  and 
oversees  this  contract  as  the  Contracting  Officer's  Technical  Representative  (COTR). 
ESU  Alameda’s  Quality  Assurance  Evaluators  (QAE)  constantly  monitor  the  quality  and 
performance  of  the  civilian  contractor  to  ensure  timely  and  thorough  support  is  achieved. 

Casualty  Response 

ESU  Alameda  coordinates  all  maintenance  and  logistics  actions  required  to  quickly 
resolve  equipment  failures  published  as  Electronic  Casualty  Reports  (CASREP)  for  afloat 
and  ashore  units  alike.  Depending  on  the  type  of  unit  involved,  specialized  sections  within 
ESU  respond  to  each  CASREP  by  arranging  for  technical  assistance  and/or  corrective 
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repairs  through  a  private  contractor  or  other  resources.  This  is  ESU  Alameda’s  number 
one  mission  priority. 

Telecommunications  Support 

ESU  Alameda  maintains  two  telephone  (TT)  shops:  one  centrally  located  on  Coast 
Guard  Island  in  Alameda  California  which  supports  all  Northern  California  units,  and  one 
in  San  Pedro  California  which  supports  all  Southern  California  units.  These  two  shops 
maintain  all  telecommunications  systems  which  are  not  currently  covered  by  private 
contract.  In  addition,  these  shops  are  responsible  for  the  Bay  Area  Communications 
System,  a  very  large  Coast  Guard  owned  microwave  system. 

Project  Assistance 

ESU  Alameda  acts  as  the  liaison  between  the  district  staff  elements  and  operational 
platforms  and  the  Maintenance  and  Logistics  Command  electronics  section  MLCP(t). 
ESU  frequently  assists  the  Maintenance  and  Logistics  Command  or  district  staff  in 
coordination  of  equipment  installations  and  other  project  functions. 

Pipeliner  Staging 

ESU  Alameda  serves  as  a  staging  area  for  Electronic  Technicians  (ETs)  awaiting 
advanced  schools  for  specific  shipboard  equipment.  This  assistance  to  Coast  Guard 
cutters  prepares  the  new  technician  to  transfer  afloat.  While  awaiting  these  schools,  ESU 
exposes  pipeliners  to  as  many  facets  of  the  ET  world  as  possible,  including  hands-on 
electronics  repair  and  maintenance  training. 
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As  previously  mentioned,  ESU  Alameda  primarily  performs  ongoing  electronics 
maintenance  repair  and  project  installations  for  other  governmental  commands  located 
within  the  boundaries  of  the  Eleventh  Coast  Guard  District.  Due  to  the  nature  of  their 
jobs,  ESU  Alameda  acts  as  liaisons  with  many  organizations  to  provide  fimding,  parts, 
logistics,  and  technical  assistance.  In  addition,  ESU  Alameda  works  with  both  contracted 
and  military  sources  as  well  as  government  employees  both  inside  and  outside  of  their  span 
of  control. 


3.  Organization 

ESU  Alameda  is  functionally  and  geographically  organized  to  place  support 
technicians  and  contract  shops  as  close  to  their  customers  as  possible  while  maintaining 
functional  specialization  of  employees.  ESU  Alameda’s  several  detachments  and 
contractor  shops  are  located  throughout  the  Eleventh  Coast  Guard  District. 

After  the  implementation  of  the  Coast  Guard  Streamlining  initiative  (explained 
later  in  this  chapter),  ESU  Alameda’s  internal  organization  resembles  that  found  in  Figure 
3.3. 
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Figure  3.3  ESU  Oi^anization,  [Ref.  19]. 


4.  Existing  Technology 

The  Coast  Guard  is  transitioning  from  a  proprietary  computer  system  to  a 
Windows  NT  3.5  system  using  the  NDcrosoft  Office  95  software  suite.  ESU  Alameda  just 
received  this  new  NT  based  computer  system  after  using  a  14  year  old  proprietary  system 
since  inception  of  the  command.  However,  they  are  planning  to  upgrade  to  NT  4.0  and 
the  office  97  suite  within  the  timelines  of  this  project  and  request  intranet  and  database 
^prototype  development  for  the  newer  platforms.  The  use  of  these  computer  systems  is 
rrfatively  new  to  ESU  Alameda  and  several  small  databases  have  been  developed  for 
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individual  use.  HoAvever,  the  existing  databases  incorporate  data  duplication  and  may  not 
properly  address  all  interest  of  the  command  at  this  time.  The  two  design  teams  will 
examine  the  data  used  and  develop  new  databases  to  properly  meet  the  command’s 
operational  requirements  while  preventing  data  duplication. 

ESU  Alameda  will  establish  a  working  NT  4.0  networked  platform  suitable  for 
their  organization  before  this  prototype  will  be  implemented  onto  their  system  by  a 
separate  thesis  design  team.  Although  this  creates  a  challenge  for  obtaining  feedback  for 
graphical  user  interface  development,  this  delay  will  not  prevent  the  analysis  of  existing 
data  and  the  correlation  of  such  data  for  prototype  intranet  specification  development 
which  is  the  primary  objective  of  this  thesis. 

5.  Contributing  Factors 

Between  1994  and  1998  the  Coast  Guard  reduced  their  budget  by  $400  million 
dollars  by  downsizing  forces  by  approximately  4000  billets  and  streamlining  the 
organization.  Downsizing  involves  drastic  changes  to  the  existing  persoimel  staffing  levels 
but  does  not  change  the  mission  and  responsibility  of  any  organization.  For  every  person 
cut,  another  person  must  pick  up  that  additional  workload.  This  has  two  major  impacts  on 
ESU  Alameda; 

♦  fewer  people  on  the  operational  platforms  is  likely  to  cause  more  requests  for 
administrative  and  technical  types  of  assistance  not  directly  associated  with  an 
equipment  casualty. 
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♦  Many  levels  of  technical  support  previously  associated  with  the  operational 
units  will  now  be  the  primary  responsibility  of  ESU  Alameda.  However,  by 
virtue  of  downsizing,  this  responsibility  will  not  come  with  the  same  levels  of 
support  personnel  assigned. 

Since  ESU  Alameda’s  billet  strength  did  not  proportionally  accompany  their  new 
levels  of  responsibility,  the  remaining  ESU  personnel  must  now  perform  a  much  larger 
mission,  with  a  notably  smaller  staff  than  had  previously  accomplished  the  same  tasks. 

Driven  by  streamlining  and  enabled  by  ESU  Alameda’s  new  computer  network,  an 
analysis  of  critical  support  processes  will  enable  the  design  of  a  prototype  intranet  which 
could  effectively  minimize  the  time  required  to  perform  ESU  tasks. 

6.  Special  Requests 

Based  on  private  discussions  held  Avith  the  command  staff  and  the  workers 
performing  the  jobs,  it  was  decided  to  forego  a  ranking  analysis  of  processes  for  Intranet 
development  and  rank  the  major  concerns  and  challenges  of  the  command.  This  list 
quickly  molded  itself  based  on  controllable  events,  and  it  was  decided  to  attack  two  of  the 
most  challenging  events  of  the  ESU.  These  challenges  are  complex  and  primarily  exist 
because  of  Coast  Guard  streamhning,  but  are  within  the  control  of  the  command.  These 
two  requests  are: 

1 .  Analyze  existing  business  processes  and  identify  areas  where  administrative 
tasks  such  as  leave  scheduling,  personnel  evaluations,  and  communications  could  be 
improved.  This  system  should  push  down  evaluation  deadlines  and  push  up  travel  and 
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leave  requests  without  requiring  any  wasted  time  tracking  down  paperwork  from  desk  to 
desk,  or  relying  on  self  made  transcribes  as  reminders  of  critical  reporting  dates. 

2.  Develop  a  business  model  to  automate  internal  funding  request,  parts 
orders,  parts  updates,  and  enable  a  push  down  follow-up  prompt  to  prevent  human 
oversights.  The  system  should  enable  any  person  within  the  command  to  find  out  the 
status  of  the  part  from  initial  order  to  delivery  without  requiring  the  assistance  of  another 
ESU  employee. 

C.  CONCLUSION 

This  chapter  provided  an  overview  of  Electronic  System  Support  Unit  (ESU) 
Alameda  including  a  brief  history  of  the  unit,  an  overview  of  the  command’s  functional 
organization,  and  mission  objectives.  Finally,  those  forces  extrinsically  motivating  the 
need  for  internal  changes  were  introduced  along  with  the  command’s  critical  requests  for 
the  intranet  design  team.  The  following  chapter  focuses  on  the  prototyping  process  using 
the  prototype  development  model. 
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IV.  THE  DESIGN  PROCESS 


A.  INTRODUCTION 

The  design  of  a  business  application  usually  begins  as  a  vague  concept  to  either 
improve  an  existing  process  or  establish  a  means  to  resolve  an  existing  conflict.  This 
chapter  will  examine  the  design  process  by  looking  at  two  of  the  most  widely  used  models, 
the  waterfall  model  and  the  rapid  prototyping  model.  Next,  a  review  of  the  project  scope 
and  operating  environment  will  be  accomplished  and  compared  against  the  strengths  and 
weaknesses  of  these  two  models.  Finally,  the  methodology  used  to  gather  data  and  the 
means  of  establishing  the  prototype  specifications  will  be  presented. 

B.  DESIGN  MODELS 

Once  the  need  for  a  business  application  is  established  it  can  be  viewed  as 
transitioning  through  a  series  of  developmental  phases.  Usually,  a  product  is  conceived 
through  an  individual’s  idea,  conceptually  coming  from  any  level  within  an  organization. 
The  idea  must  then  compete  for  funding  and  political  ranking  within  the  organization  and 
then  proceed  through  some  form  of  design,  implementation,  and  maintenance  phase.  The 
evolution  of  this  development  could  enhance  or  degrade  the  desired  purpose  for  the 
application  depending  on  how  the  design  process  is  handled.  Too  little  control  over 
development  could  result  in  an  environment  where  everything  becomes  chaotic  and  the 
focus  for  the  project  is  lost.  Too  much  control  over  development  could  create  an 
environment  where  the  design  becomes  policy  driven  to  the  point  where  even  serious 
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design  issues  unsuccessfully  compete  against  a  rigid  design  policy.  Without  an  effective 
design  model  in  place,  certain  obstacles  for  success  are  predictable,  such  as: 

♦  The  final  project  was  not  what  the  customer  wanted  (policy  driven  instead  of 
problem  driven) 

♦  The  final  project  takes  to  long  to  develop  and  goes  over  budget 

♦  Specifications  for  functionality  keep  chan^g 

♦  The  need  for  the  project  changes 

To  enhance  the  successful  development  of  an  application,  some  form  of 
development  methodology  must  be  employed  to  manage  the  intent  of  the  project  and  the 
environment  of  the  organization.  This  methodology  must  define  the  critical  milestones  of 
an  organization,  establish  some  form  of  development  accountability,  address  the  risks  of 
the  project  in  the  initial  planning  stages,  and  define  the  variables  and  priorities  which  will 
ultimately  drive  the  projects  scheduling  and  features. 

Several  design  methodologies  exist  and  the  explicit  or  combined  uses  of  any  of 
them  will  largely  be  determined  by  the  needs  of  both  the  organization  and  design  team. 
Each  design  case  will  be  unique  and  each  design  methodology  will  possess  many  strengths 
and  weaknesses  for  each  case. 

To  better  understand  the  potential  contributions  the  two  most  popular  design 
methodologies  offer  in  the  ESU  Alameda  Prototype  development,  each  will  be  defined 
below  and  then  compared  to  ESU  Alameda’s  situation. 
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1.  The  WaterfaU  Model 


Until  the  1980’s  the  waterfall  model  was  the  only  widely  accepted  life-cycle  model 
[Ref  20,  p.  45],  One  of  the  primary  advantages  of  the  waterfall  model  is  the  ability  to 
bring  unity  to  projects  of  a  very  large  scale;  especially  when  involving  several  different 
design  groups.  By  using  detailed  documentation  from  the  point  of  project  initiation 
through  the  life  of  the  project,  the  various  design  teams  are  able  to  effectively  bring 
organizational  unity  to  the  design  effort.  Detailed  documentation  also  facilitates  future 
maintenance  actions  for  a  developer  who  will  add  additional  functionality  to  an  application 
when  the  original  designer  is  either  no  longer  available,  or  simply  can’t  remember  what 
was  done.  For  this  reason,  the  waterfall  model  is  a  valid  candidate  for  use  if  the  project  is 
either  very  large,  different  groups  will  perform  the  design,  or  the  future  availability  of  the 
original  designers  are  unknown  and  future  maintenance  of  the  application  is  a  concern. 

The  use  of  the  waterfall  model  does  have  some  drawbacks  which  must  be 
considered.  Since  the  waterfall  model  relies  on  accurate  documentation,  it  is  only  a  good 
choice  for  development  if  the  customer  knows  exactly  what  they  want  the  application  to 
do  and  can  effectively  communicate  those  requirements  in  wntten  context  with  the 
designer.  For  this  reason  the  success  of  the  waterfall  model  is  heavily  influenced  by  both 
the  customer  and  designer  having  a  thorough  imderstanding  of  the  design  concept  and 
needs  of  the  organization.  A  diagram  of  the  waterfall  model  is  presented  in  Figure  4. 1 
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When  using  the  waterfall  model,  the  customer  performs  the  first  task  by 
meticulously  determining  their  business  environment  and  defining  the  specific  requirements 


they  need  from  the  developer’s  application.  Once  the  exact  requirements  are  known,  the 
organization  must  translate  those  requirements  into  a  written  specification  stating  exactly 
what  the  completed  product  will  accomplish.  As  previously  mentioned,  this  is  one  of  the 
weaknesses  with  the  waterfall  model.  Since  the  success  of  the  entire  design  rests  with  the 
completeness  of  the  specification,  any  missing,  contradictory,  or  ambiguous  wording  may 
result  in  serious  consequences  ranging  from  a  loss  in  productivity,  wasted  funds,  or 
changes  in  political  standing  for  an  organization.  Even  if  performed  properly,  the  rigid 
implementation  of  each  phase  combined  with  the  verification  and  documentation  tasks 


44 


often  leads  to  extensive  project  management  requirements,  cost  overruns,  project  delays, 
and  products  that  fail  to  meet  the  customer’s  operational  requirements. 

If  the  developer  has  any  diflBculty  associating  the  requirements  fi'om  the 
specifications,  feedback  is  provided  to  the  organization.  When  this  occurs,  the 
specifications  must  be  revised  before  the  development  can  continue.  This  is  denoted  by 
the  feedback  arrows  originating  from  a  lower  positioned  box  to  an  upper  positioned  box  in 
Figure  4.1.  An  example  of  this  would  be  the  arrow  from  the  Design  box  back  to  the 
Specifications  box. 

As  previously  mentioned,  the  waterfall  model  is  dynamically  implemented  by  the 
use  of  feedback  loops  between  each  stage  of  succession  to  resolve  any  found 
discrepancies.  Each  stage  signifies  the  completion  of  a  development  milestone  by 
providing  additional  documentation  to  the  next  segment.  Using  this  methodology,  the 
waterfall  model  allows  for  revisions  of  specifications,  design,  and  associated 
documentation  at  all  stages  of  the  of  the  development  cycle.  This  iterative  process  helps 
ensure  correct  documentation  exists  when  the  project  is  finally  complete,  but  can  be 
extremely  time  consuming  to  perform. 

Another  drawback  to  the  waterfall  methodology  is  the  requirement  for  extensive 
customer  testing  late  in  the  development  life  cycle.  Since  the  waterfall  model  is  a  time 
intensive  process  there  is  a  distinct  possibility  the  customer’s  requirements  may  either 
change  or  no  longer  be  required  before  a  testable:  application  can  be  developed. 
Therefore,  the  waterfall  model  does  not  lend  itself  to  continual  risk  assessment  which  may 
be  a  desired  prerequisite  of  the  customer.  Further,  if  the  customer  fails  to  fiilly  understand 
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the  technical  documentation  produced,  a  perception  of  milestone  acceptance  may  be 
viewed  by  the  developer.  There  exists  a  good  chance  that  neither  side  will  realize  the 
project  fails  to  meet  expectations  until  significant  resources  are  consumed  and  the  product 
reaches  the  testing  milestone.  Depending  on  the  complexity  of  the  errors,  the  entire 
specification  and  project  may  require  rework  or  even  termination.  A  means  of  reducing 
the  time  required  for  development  and  ability  to  obtain  customer  feedback  earlier  in  the 
development  life-cycle  is  a  major  reason  rapid  prototyping  was  developed. 

2.  The  Rapid  Prototyping  Model 

This  application  developmental  approach  is  a  systems  development  methodology 
created  to  rapidly  deploy  a  desired  application.  By  unifying  the  ideas  and  focusing  the 
efforts  between  developers  and  the  actual  users  of  the  application,  the  amount  of  time  and 
funding  required  to  design  and  implement  an  application  can  be  reduced.  The  concept 
rehes  heavily  on  customer  involvement  throughout  the  design  phases  where  a  rapidly 
developed  prototype  is  used  as  an  instrument  to  converse  requirements  and  resolve 
misperceptions.  In  this  concept,  the  prototype  is  defined  as  a  working  model  that  is 
functionally  equivalent  to  a  subset  of  the  product  [Ref  20,  p.  49].  The  rapid  prototyping 
development  process  is  portrayed  in  Figure  4.2. 
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In  this  model  the  initial  requirements  are  gathered  by  means  of  interviews, 
questionnaires,  or  any  other  means  available  to  the  analyst.  The  data  or  processes  are 
examined  using  CASE  tools  and  the  conceptual  ideas  of  the  desired  application  are  rapidly 
developed  using  any  quick  design  tool  available  which  is  capable  of  rapid  change.  The 
analyst  and  end  users  then  work  together  using  the  customers  feedback  to  iteratively 
resolve  aU  process  and  data  misperceptions  and  gain  a  better  understanding  of  the 
application’s  requirements.  When  completed,  the  prototype  becomes  the  specification  for 
the  actual  product  development. 

Using  the  rapid  prototyping  methodology  enables  the  customer  and  developer  to 
quicldy  agree  on  the  applications  functionality.  When  contrasted  with  the  waterfall  model, 
the  need  for  feedback  and  time  consuming  rework  between  successive  layers  is 
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significantly  reduced,  making  the  design  timeline  linear  instead  of  exponential.  This  is 
largely  due  to  the  fact  the  user  is  able  to  see  errors,  clarify  misperceptions,  and  offer 
feedback  at  the  initial  development  phase  instead  of  the  later  implementation  testing  phase 
associated  with  the  waterfall  model.  For  this  reason,  the  use  of  rapid  prototyping  is  an 
ideal  methodology  for  customer’s  who  possess  any  of  the  following  traits: 

♦  Unsure  what  they  really  want 

♦  Have  changing  operational  requirements 

♦  An  initial  level  of  risk  assessment  is  desired  before  obligating  for  development 

♦  There  exist  a  quick  need  for  the  application 

♦  Development  is  not  complex  and  does  not  require  several  disjointed  teams 

In  the  rapid  prototype  model,  the  completion  of  the  specification  means  a 
milestone  is  reached  where  the  customer  has  validated  the  functionality  of  the  prototype 
and  actual  design  of  the  application  can  begin.  Since  the  functionality  of  the  prototype  is 
confirmed  during  the  initial  stages  of  design,  the  chances  of  an  incorrect  specifications  are 
greatly  reduced.  Therefore,  rapid  prototyping  offers  a  level  of  risk  assessment  for  those 
organizations  who  are  not  sure  if  their  requirements  are  technically  feasible. 

The  implementation  phase  of  both  the  waterfall  and  rapid  prototyping  model  often 
reveals  design  faults  and  causes  additional  delays.  However,  because  the  prototype 
actually  tested  some  functionality  of  the  application,  the  quantity  of  design  faults  using 
rapid  protot5/ping  could  arguably  be  less. 
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The  use  of  the  rapid  prototype  methodology  offers  many  advantages  over  the 
waterfall  model  but  also  adds  additional  challenges  to  the  design  process  if  improperly 
managed.  One  of  the  largest  errors  made  in  the  rapid  prototype  development  is  the  use  of 
the  original  prototype  for  the  actual  application.  This  alternative  means  is  usually  an 
unwise  developmental  methodology  which  typically  refines  the  prototype  until  it  in  itself 
becomes  the  actual  application  as  shown  in  Figure  4.3.  In  practice,  this  concept  does 
nothing  more  than  waste  time  and  money  attempting  to  fix  a  product  that  was  never 
intended  to  meet  the  operational  requirements  of  the  organization  and  therefore  should  not 
be  used. 


Figure  4.3  Unwise  Version  of  Rapid  Prototyping,  [Ref.  20,  p.  52] 
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C.  SCOPE 

The  scope  of  this  project  encompasses  the  conceptual  design  of  a  baseline  Intranet 
for  ESU  Alameda.  The  prototype  makes  every  attempt  to  change  existing  business 
models  by  decentralizing  existing  tasks  to  the  lowest  possible  level  so  as  to  free  up  critical 
command  personnel.  Rather  than  a  complete  system,  the  prototype’s  primary  objective  is 
to  evaluate  existing  processes  and  define  requested  specifications  for  ESU  Alameda 
suitable  for  intranet  development.  Additional  areas  suitable  for  further  development  and 
evaluation  will  be  presented  in  chapter  five.  The  prototype  includes  the  graphical  design 
of  the  baseline  intranet,  administrative  section,  and  specifications  development  for  the 
supply  tracking  system.  The  primary  objective  of  this  team  is  to  gain  an  understanding  of 
existing  business  challenges,  analyze  existing  processes,  define  ways  to  improve  these 
processes  with  intranet  development,  define  a  set  of  specifications  for  ESU  Alameda,  and 
offer  feedback  assistance  to  another  design  team  for  the  actual  coding  and  implementation 
of  the  prototype  intranet  if  required. 

To  develop  this  prototype,  CASE  tools  will  be  used  to  analyze  the  business 
processes.  However,  at  the  request  of  ESU  Alameda,  Commercial  Off  The  Shelf  (COTS) 
Software  will  be  used  to  develop  the  conceptual  design  and  specifications.  By  using 
COTS,  the  design  remains  scalable  to  new  mission  requirement  and  future  development  by 
contracted  sources  as  deemed  necessary  by  ESU  Alameda.  For  this  reason,  existing 
Microsoft  web  editors,  database  software,  and  office  products  found  at  ESU  Alameda  will 
be  used  by  the  design  teams. 
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D.  OPERATING  ENVIRONMENT 


As  previously  mentioned,  ESU  Alameda  recently  upgraded  from  a  14  year  old 
proprietary  computer  system  to  a  networked  architecture  using  Pentium  based  machines 
with  Microsoft’s  NT  3.5  operating  system  and  the  office  95  professional  business  suite.  In 
addition,  ESU  Alameda  is  planning  to  upgrade  to  the  Microsoft  NT  4.0  operating  system 
and  the  office  97  professional  business  suite  within  the  next  three  months.  ESU  Alameda 
would  like  to  use  their  newer  software  to  minimize  additional  training  required  for  then- 
employees  and  therefore  request  all  prototype  applications  be  developed  using  the 
mentioned  technologies.  Using  existing  software  will  also  enable  this  prototype 
development  to  remain  scalable  and  capable  of  rapid  changes  by  the  organization  to  meet 
the  evolving  mission  requirements  of  ESU  Alameda.  With  the  recent  transition  to  this 
new  hardware  and  software,  a  baseline  system  is  in  need  of  development  to  enhance 
communications  while  minimizing  data  duplication. 

In  addition  to  the  above  technical  challenges,  ESU  Alameda  recently  doubled  in 
size  as  the  result  of  a  Coast  Guard  organizational  streamlining  program.  This  means  that 
ESU  Alameda  has  now  absorbed  several  duties  not  previously  under  their  control  and  is 
now  required  to  perform  a  much  larger  mission,  with  a  notably  smaller  staff  than  had 
previously  accomplished  the  same  tasks.  Therefore,  ESU  Alameda  requested  this  team 
study  their  current  business  model  and  identify  ways  their  new  NT  based  platform  could 
enhance  the  growing  organization,  making  it  more  efficient;  specifically  in  the  areas  of 
administrative  oversight  and  supply  tracking. 
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E.  CHOSEN  METHODOLOGY 

ESU  Alameda  is  currently  experiencing  rapid  changes  in  organizational  structure, 

duties,  and  operating  guidelines  as  a  direct  result  of  the  Coast  Guard  streamlining 

initiative.  However,  even  with  these  business  challenges,  the  organization  continues  to 

maintain  an  intrinsic  desire  to  improve  their  support  services.  This  motivation  is  largely 

due  to  the  commands  decentralized  use  of  innovation,  a  concept  that  is  clearly  wntten 

vdthin  the  Commanding  OflScer’s  operating  instructions; 

I  expect  each  of  you  to  improve  our  system  of  doing  business,  to  be 
innovative,  and  to  think  for  yourselves.  If  a  policy  prevents  improvement, 
or  hinders  service  to  the  customer,  point  it  out  via  the  chain  of  command, 
and  I  will  work  on  it  [Ref.  19]. 

To  meet  the  needs  of  the  evolving  ESU  organization,  it  was  decided  to  use  the 
rapid  prototyping  methodology  over  the  waterfall  methodology  for  this  development. 
This  decision  was  largely  justified  for  the  following  reasons: 

♦  ESU  Alameda  did  not  have  the  time,  background,  or  clear  idea  of  the  needed 
functionality  of  the  application  to  enable  a  detailed  specification  to  be 
developed  by  the  organization.  The  use  of  rapid  prototyping  alleviates  them  of 
this  burden  and  instills  a  clearer  understanding  of  the  development  task  by  both 
the  organization  and  developer 

♦  ESU  Alameda  is  evolving  and  susceptible  to  rapid  changes  to  meet  mission 
objectives.  The  ability  to  meet  these  potential  changes  is  better  suited  to  rapid 
prototyping 
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♦  Critical  ESU  personnel  are  scheduled  for  transfer,  making  feedback  difficult  if 
not  impossible.  Rapid  prototyping  requires  the  majority  of  the  feedback 
initially  and  reduces  the  need  for  feedback  between  successive  development 
stages  later  on 

♦  Available  time  of  both  the  ESU  and  development  team  was  limited  to  five 
months,  making  the  rapid  prototype  the  better  choice 

As  previously  mentioned,  in  the  design  of  the  ESU  Alameda  Intranet  prototype  a 
specific  methodology  was  employed.  Coupled  with  a  short  project  development  timeline 
and  the  lack  of  clear  specifications  firom  the  user,  the  waterfall  method  was  rejected. 
Instead,  the  ESU  Alameda  prototype  intranet  was  developed  as  two  different  sets  of 
specifications;  one  modeling  the  command’s  administrative  issues  and  one  modeling  the 
decentralized  use  of  data  for  the  command’s  supply  tracking  system.  Both  prototypes 
used  similar  rapid  prototyping  methodologies  and  obtained  input  fi'om  all  team  members. 
However,  the  scale  and  complexity  of  the  two  systems  did  not  allow  the  same 
specification  development  tools  to  be  used.  For  this  reason  the  two  design  teams 
unilaterally  analyzed  data,  provided  input  for  system  functionality,  and  developed 
graphical  interfaces.  However,  the  development  of  the  prototype  specifications  was 
separated  into  two  separate  teams*,  with  each  team  writing  a  separate  thesis. 


*  LT  Ralph  Benhait  and  LT  Dean  Dardis  comprised  the  Supply  Tracking  System  team  and  developed  this 
thesis  using  Microsoft  Access  for  the  specification  development  tool,  while  LT  Todd  Hannah  comprised 
the  Persoimel  Administration  team  and  developed  a  separate  thesis  using  Microsoft’s  Active  Server 
Scripting  as  the  specification  development  tool. 
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F.  DATA  CAPTURING 


One  of  the  core  components  in  creating  a  successful  application  is  the  gathering  of 
information.  At  the  very  start  of  the  project  the  analyst  must  obtain  an  understanding  of 
the  existing  systems  in  use  and  determine  how  those  systems  interact  with  the  user’s 
processes.  In  addition  to  existing  hardware  and  software  constraints,  the  organization’s 
objectives,  short  and  long  range  goals,  political  standing,  current  stakeholders,  and  current 
challenges  must  be  addressed.  Depending  on  the  available  time  the  organization  and 
analyst  have,  one  or  more  of  the  following  methods  could  be  used  to  obtainmg  this 
information; 

♦  Interviewing  the  users,  managers,  and  stakeholders  of  the  organization.  This  is 
thorough,  but  time  consuming 

♦  Interview  groups  of  users  of  the  organization.  This  takes  less  time  but  may  not 
reveal  all  the  details  that  are  required 

♦  Develop  and  distribute  questionnaires 

♦  Obtain  and  analyze  existing  documents,  forms,  and  operating  instructions. 
This  helps  ensure  the  proper  uses  of  data  are  understood  and  provides  a  means 
to  develop  graphical  interfaces  which  are  already  familiar  to  the  users.  It 
becomes  a  key  part  of  analyzing  processes  which  will  be  further  described  in 
chapter  sbc 

♦  Directly  observe  workers  in  action 

For  this  project  an  initial  trip  was  made  at  the  onset  to  gather  data  and  gain  an 
understanding  of  ESU  Alameda’s  business  model,  challenges,  desires,  and  political 
standing.  Appendk  A  is  a  trip  report  which  records  the  events  of  this  trip  and  defines  the 
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ways  information  was  gathered.  In  short,  forms  and  documents  were  gathered,  structured 
group  and  individual  interviews  were  conducted,  and  a  poHtical  risk  assessment  for  the 
project  was  performed  by  talking  to  all  members  of  the  organization  as  well  as  external 
stakeholders.  Based  on  private  discussions  held  with  the  command  staff  and  the  workers 
performing  the  jobs,  it  was  decided  to  forego  a  ranking  analysis  of  processes  for  intranet 
development  and  rank  the  major  concerns  and  challenges  of  the  command.  This  list 
quickly  molded  itself  based  on  controllable  events,  and  it  was  decided  to  attack  the  top 
two  challenges  of  the  ESU;  the  personnel  administration  and  supply  tracking  systems. 
These  challenges  are  complex,  but  within  the  control  of  the  command.  Analyzing  existing 
processes  and  data  to  develop  new  business  processes  to  free  up  the  command’s  limited 
personnel  resources  became  the  primary  focus  of  this  project.  The  analysis  of  this  data  is 
performed  in  chapter  six. 

G.  CONCLUSION 

A  background  of  several  known  design  methodologies  was  provided  to  the  reader 
to  enhance  the  understanding  of  the  methodology  chosen  for  this  project.  Next,  a  review 
of  the  projects  scope  and  operating  environment  was  accomplished  to  enable  the  reader  to 
compare  the  development  climate  against  the  strengths  and  weaknesses  of  these  two 
models.  Finally,  the  means  used  to  collect  information  for  this  project  was  presented. 
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V.  CANDroATE  APPLICATIONS  FOR  BUSINESS  SOLUTIONS 


A.  INTRODUCTION 

Chapter  five  will  address  the  potential  functionality  of  the  ESU  Alameda  intranet 
by  prowding  a  brief  review  on  the  types  of  applications  typically  used  within  corporate 
intranets,  and  then  offer  suggestions  to  modify  this  list  for  military  application 
development.  The  majority  of  this  chapter  vwU  then  focus  on  the  conceptual  ideas  for 
applications  which  would  offer  significant  improvements  to  the  current  business  processes 
of  ESU  Alameda. 

Since  the  primary  purpose  of  this  chapter  is  to  present  additional  applications 
which  ESU  Alameda  may  desire  to  add  to  their  intranet  in  the  future,  after  the  command 
has  developed  an  understanding  of  the  capabilities  and  maintenance  requirements  of  then- 
new  system,  it  could  be  used  as  the  conclusion  to  this  thesis.  However,  it  was  decided  to 
present  the  reader  with  this  information  prior  to  revealing  the  data  processes  of  chapter  six 
and  specification  development  of  chapter  seven  to  enable  a  better  understanding  of  the 
magnitude,  potential  interrelations,  and  development  challenges  of  some  the  proposed 
applications. 

B.  A  TYPICAL  REASON  FOR  AN  INTRANET  (REVISITED) 

As  previously  mentioned  in  chapter  two,  an  organization  could  use  intranet 
technologies  in  many  different  ways  to  enhance  their  capabilities  and  efficiencies.  These 
ways  are  repeated  here  for  clarity. 
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The  Gartner  Group  classifies  intranet  proliferation  and  development  into 
three  levels.  Level  1  intranets  consist  of  low-level  implementations,  static 
publishing,  or  simply  moving  content  on-line.  Level  11  intranet 
development  centers  around  enabling  core  day-to-day  applications  for  web 
use  and  using  the  intranet  as  a  workgroup  computing  platform.  Level  III 
intranets  will  be  characterized  by  a  large  base  of  web-enabled  applications, 
a  consolidation  of  dozens  of  Application  Program  Interfaces  (API’s)  used 
in  Level  n,  more  secure  web  servers,  and  more  powerful  development 
tools.  Most  companies  spent  1996  testing  intranet  waters  at  level  I. 
Mainstream  organizations  are  expected  to  develop  Level  n  intranets  in 
1997  and  1998.  By  1999,  top  organizations  are  expected  to  plateau  at 
Level  in  [Ref  3,  pp.  80-81]. 

Before  we  look  at  specific  intranet  applications  ESU  Alameda  may  want  to  use  in 
cultivating  their  new  business  model,  a  review  of  a  the  typical  list  of  intranet  application 
firom  chapter  two  will  help  remind  us  of  some  possible  alternatives  businesses  are  currently 
choosing  fi'om  [Ref  2,  pp.  8-9]. 

♦  Electronic  Mail 

♦  Directories 

♦  Organization  charts 

♦  Memos 

♦  Persormel  manuals 

♦  Benefits  information 

♦  Newsletters  and  publications 

♦  Systems  user  documentation 

♦  Training 

♦  Newsgroups 

♦  New  extracts 

♦  Job  postings 

♦  Sales  reports 

♦  Financial  reports 

Although  some  of  the  intranet  applications  mentioned  above  are  applicable  to 
commercial  organization,  they  don’t  fully  suit  the  military  organization.  Largely  in  part 
because  commercial  organization  are  profit  driven,  usually  trying  to  sell  a  product  or 


♦  Customer  information 

♦  Quality  statistics 

♦  Vendor  information 

♦  Product  information 

♦  Marketing  brochures,  videos, 
presentations 

♦  Product  development 
information  and  drawings 

♦  Inventory  information 

♦  Network  management 

♦  Asset  management 

♦  Supply  and  component 
catalogs 
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service  to  whomever  will  pay.  Where  in  a  military  command  like  ESU  Alameda,  the 
organization  is  budget  driven  with  the  services  offered  and  customer  base  already 
established.  Specializing  those  applications  found  above  to  mirror  the  functional 
requirements  of  a  typical  mihtary  support  organization  would  more  closely  resemble  the 
following  list. 


♦  Leave,  temporary  duty,  and 
persormel  tracking 
information 

♦  Supply  ordering  and  tracking 
information 

♦  Electronic  Mail 

♦  Phone  directories 

♦  Maintenance  knowledge  base 
and  scheduling 

♦  Contact  knowledge  base 

♦  Organization  charts 

♦  Personnel  manuals 

♦  Newsletters  and  publications 

♦  Manuals  and  technical 
references 

♦  Newsgroups 

♦  Billet  transfer  listings 


♦  Budget,  quality,  and  customer 
status  reports 

♦  Customer  information 

♦  Performance  measurements 

♦  Historical  Coast  Guard 
information 

♦  Product  information 

♦  Training  documentation 
brochures,  videos, 
presentations 

♦  Project  information  and 
drawings 

♦  Network  management 

♦  Asset  management 

♦  Supply  and  component 
catalogs 


C.  A  BACKGROUND  ON  INTRANET  APPLICATIONS 

When  evaluating  an  application  for  intranet  development,  there  needs  to  be  a  clear 

understanding  of  how  the  user  will  interact  with  the  application,  what  business  processes 

the  application  will  assist  the  user  in  performing,  and  which  pieces  of  data  will  be  involved. 

It  is  generally  accepted  that  well-designed  applications  today  have  clear 
divisions  between  user  interface,  business  rules,  and  data.  This  logical 
division  of  an  application  allows  significant  flexibility  in  adapting  the  user 
interface  over  time,  or  applying  the  business  rules  to  new  data  sources 
[Ref  21] 
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As  previously  mentioned,  this  project  will  develop  a  specification  for  a  baseline 
intranet  for  ESU  Alameda.  The  user  interface,  business  processes,  and  data  used  for  this 
project  will  be  analyzed  and  presented  in  chapter’s  six  and  seven. 

One  purpose  for  developing  web-based  applications  is  to  improve  user  efficiency  in 
locating  or  distributing  information  within  an  organization.  The  types  of  applications 
which  can  be  developed  to  make  the  user  more  efficient  are  immense  and  only  limited  by 
the  organizations  creativity,  employee  computing  knowledge,  or  available  funding  to 
outsource  application  development.  The  applications  which  can  be  developed  by  the 
organization’s  employees  or  development  firms  are  generally  placed  into  one  of  three 
types  of  categories. 

1.  Publishing  Applications 

These  applications  are  essentially  one-to-many  communication  systems 
where  information  from  a  department,  section,  or  workgroup  is  posted  and 
made  available  to  the  entire  organization.  Application  of  this  nature  are 
normally  static,  easy  to  implement,  and  often  provide  the  most  immediate 
and  tangible  monetary  savings.  These  savings  normally  take  the  form  of 
reduced  production,  printing,  reproduction,  and  shipping  costs  associated 
with  the  paper  on  which  the  information  was  previously  printed. 

2.  Transaction  Applications 

These  applications  are  two-way  interactive  exchanges  such  as  requesting  or 
providing  information  to  an  organizational  database.  With  these 
applications,  the  user  normally  queries  a  database  and  in  return  receives  a 
dynamically  populated  HTML  page  with  the  results  of  the  query.  These 
applications  are  more  difficult  to  produce  than  the  publishing  applications 
because  they  normally  require  some  programming.  These  are  the 
applications  that  empower  users  by  enabling  them  to  locate  information  on 
their  own  initiative.  Transaction  applications  enhance  productivity  by 
removing  the  constraints  that  previously  bound  individuals  to  completing 
request  forms  or  playing  telephone-tag  with  the  information  source. 
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Information  can  be  retrieved  by  the  user  when  desired  and  on  demand 
when  distributed  using  an  intranet. 

3.  Community  Applications 

These  applications  are  many-to-many,  collaborative  interactions  that 
facilitate  the  direct  exchanges  of  information  between  members  in  a 
department,  section,  or  workgroup.  This  exchange,  represents  the  start  of 
a  “thread”  that  is  available  for  others  to  review  or  add  relevant  information 
or  comments.  This  thread  would  be  listed  in  a  newsgroup  under  a  subject 
line,  the  authors,  and  an  article  number  and  would  be  available  for  others  to 
investigate.  Community  applications  are  especially  effective  for  project 
teams  that  are  dispersed  throughout  a  large  geographic  area  but  who  must 
still  communicate  and  coordinate  their  efforts  in  achieving  an  assigned 
project  [Ref  22,  pp.  35-36]. 

The  remainder  of  this  chapter  will  examine  some  of  the  possible  applications  ESU 
Alameda  may  desire  to  develop  and  implemented  to  add  additional  functionality  to  the 
baseline  intranet  described  in  chapters  six  and  seven. 


D.  POTENTIAL  ESU  ALAMEDA  APPLICATIONS 

1.  Administrative  and  Personnel  Tracking  System 

The  tasks  of  planning,  coordinating,  verifying,  and  validating  many  of  the  common 
military  administrative  issues  such  as  leave  request,  temporary  duty  assignments,  duty 
routines,  and  performance  appraisals  can  be  extremely  time  consuming  for  an  organization 
to  perform.  This  is  especially  true  for  a  growing  organn^ation  such  as  ESU  Alameda.  An 
application  where  common  administrative  tasks  are  performed  online  would  prevent  the 
duplicate  and  time  consuming  efforts  currently  associated  with  routing  paperwork, 
verifying  status,  and  providing  continual  feedback  up  and  down  the  chain  of  command. 
To  make  this  concept  work,  a  client  server  model  would  be  used  with  an  administrative 
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web  application.  The  application  would  automate  commonly  used  forms  and  use  a  task 
tracking  system  to  allow  users  to  submit  routine  request  such  as  leave  and  temporary  duty 
paperwork  from  their  computer  browser.  Since  the  application  would  allow  users  to  input 
all  routing  information,  the  request  would  be  automatically  and  immediately  distributed  to 
the  next  responsible  person,  thereby  preventing  the  need  for  additional  routing  paperwork 
generation.  The  next  individual  on  the  list  would  automatically  be  notified  a  request  was 
made  and  would  be  capable  of  jumping  to  a  predefined  web  page  to  act  on  the  request. 
This  application  offers  another  time  saving  advantage  to  managers  and  supervisors  since 
they  will  no  longer  have  to  sift  through  overflowing  inboxes  looking  for  common 
documents  resquiring  action.  In  this  application,  the  manager  or  supervisor  is  presented  a 
to-do  list  view  of  all  forms  currently  in  existence  where  their  signature  is  required.  This 
enables  comparison  of  all  open  requests  and  enhances  the  decision  making  process.  Once 
acted  upon,  the  request  is  cleared  from  the  manager’s  or  supervisors  to-do  list  screen,  a 
notification  is  ^ven  to  the  requestor  and  next  individual  on  the  routing  list  automatically. 
In  addition,  a  defined  web  location  is  automatically  updated  which  users  can  view  to  see 
the  existing  status.  The  need  for  time  consuming  status  tracking  and  feedback  up  and 
down  the  chain  of  command  is  now  completely  handled  by  the  application.  The  tracking 
application  would  offer  similar  functionality  for  performance  marks.  A  to-do  style  screen 
will  update  key  individuals  automatically  when  performance  appraisals  are  due  or  behind 
schedule. 
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2.  Supply  Tracking  System 

A  customer  service  oriented  support  organization  such  as  ESU  Alameda  heavily 
relies  on  the  processes  of  ordering,  shipping,  distributing,  and  tracking  hundreds  of  supply 
parts  to  perform  their  mission.  Since  the  lack  of  any  one  of  these  critical  parts  can 
significantly  impact  Coast  Guard  operations,  an  application  which  can  track,  organize,  and 
provide  status  information  to  any  member  in  the  command  is  needed.  Specifically,  the 
application  must  decentralize  the  Storekeeper’s  (SK)  input  of  specialized  codes,  status 
tracking,  and  feedback  to  the  technicians  which  order  the  parts.  Since  key  command 
personnel  are  not  always  available  and  there  exist  a  definitive  need  for  various  personnel 
to  research  status  conditions,  the  application,  must  offer  a  mechanism  for  any  member  of 
the  command  to  gain  information  on  the  status  of  a  part.  To  offer  accountability,  the 
system  must  maintain  the  integrity  of  the  system  by  archiving  all  data  used.  Based  on 
interviews,  use  of  such  an  application  will  free  up  over  25%  of  the  SK’s  available  time  and 
allow  this  over  tasked  person  to  be  used  in  more  specialized  areas  such  as  budget 
preparations,  contracting,  planning,  and  resolution  of  difficult  requirements. 

3.  Plan  of  the  Day 

Publishing  of  the  Plan-of  -the-Day  on  web  pages  would  enable  quick  access  to 
current  information  as  well  recent  or  archived  information  that  may  be  desired  from 
personnel  returning  from  temporary  travel.  Employees  and  Coast  Guard  Reserve 
components  would  be  able  to  access  this  information  at  any  time  of  the  day  from  either 
work  or  home.  This  could  be  modified  to  include  specialized  information  for  Coast  Guard 
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Reserve  forces  to  enhance  communications  on  upcoming  training,  uniform  requirements, 
drills,  and  mustering  locations. 

4.  Command  Phone  Book  and  Email  Listing 

This  application  would  prevent  the  current  “paper”  phonebook  from  requiring 
continual  publication  and  distribution  to  remain  current.  Using  web  pages  and  search 
engine  technologies  associated  with  many  of  the  web  products  in  use  would  enable  users 
to  search  for  a  specific  person  by  name  or  duty  section.  Before  this  type  of  application  is 
implemented,  the  command  must  generate  policy  for  the  type  of  data  to  display  and 
maintenance  of  it’s  accuracy.  To  prevent  data  duplication,  this  application  should  obtain 
its  data  from  the  administrative  areas  of  the  intranet,  which  will  most  likely  be  associated 
with  a  database.  This  way,-  personal  data  on  employees  is  updated  within  the 
administrative  area  and  phone  book  at  the  same  time.  Since  the  administrative  database 
will  most  likely  contain  private  information  that  the  crevraiember  does  not  want 
publidzed,  the  command  must  determine  what  information  will  be  published  for  intranet 
access.  An  even  more  refined  listing  may  be  desired  for  extranet  customers  if  the 
command  would  like  to  make  the  phone  listing  available  to  the  other  agencies.  A  good 
addition  to  the  search  tool  in  this  application  would  be  to  use  hypertext  formatting  for 
email  listings.  This  way  a  user  could  quickly  generate  email  to  the  selected  person  by 
merely  clicking  on  the  hypertext  name  of  the  person  in  the  email  section  of  the  phone 
listing. 
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5.  Maintenance  Knowledge  Base  and  Scheduling 

Although  very  useful,  the  maintenance  of  this  type  of  application  would  need  to 
come  from  an  organization  external  to  ESU  Alameda,  and  is  therefore  outside  ESU 
Alameda’s  control.  Since  the  maintenance  procedures  and  servidng  schedules  are 
established  by  Coast  Guard  Headquarters  personnel,  the  design  and  maintenance  of  this 
application  would  be  best  suited  for  headquarters  development  and  distribution. 
Development  by  ESU  Alameda  would  require  continual  application  modifications  to  keep 
pace  with  headquarters  changes,  making  the  benefits  not  worth  the  costs  to  implement. 
Assuming  the  application  was  established  by  headquarters  and  installed,  an  ESU  Alameda 
technician  could  type  in  questions  to  aid  in  the  resolution  of  difiBcult  electronic  repairs  or 
to  gain  information  for  servicing  procedures.  A  system  to  help  technicians  schedule  and 
log  preventive  maintenance  routines  would  also  be  useful.  If  linked  to  a  headquarters 
intranet  application,  maintenance  data  could  automatically  be  tabulated  and  measured 
against  equipment  failures,  supply  levels,  and  mean  time  between  repairs  to  forecast 
mission  impact  and  budgetary  requirements. 

6.  Contact  Knowledge  Base 

Coupled  with  the  large  turnover  rates  associated  with  military  transfers,  unique 
operational  requirements,  and  ESU  Alameda’s  extensive  need  to  collaborate  with 
multitudes  of  organizations,  some  form  of  knowledge  base  needs  to  exist  to  help  newer 
persoimel  locate  key  organizations  and  personnel.  Since  the  electronics  funding, 
equipment,  and  repair  parts  used  by  the  Coast  Guard  originate  from  numerous  Coast 
Guard  and  Department  of  Defense  organizations  and  personnel,  deciding  where  to  go 
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when  equipment  fails  can  be  extremely  challenging.  This  is  especially  for  newly  assigned 
personnel.  Currently,  experience  is  used  to  link  specific  equipment  to  specific  people  and 
specific  organizations.  But  this  information  takes  time  to  learn  and  is  regularly  outdated, 
forgotten,  or  misplaced.  Even  when  the  correct  information  is  located,  large  amounts  of 
research  duplication  is  conducted  within  the  ESU  command  because  the  technology  does 
not  exist  to  enable  collaboration.  However,  with  the  installation  of  the  intranet  a  Contact 
Knowledge  Base  application  can  be  used  to  share  information,  reduce  research  times,  and 
enable  easier  updates  to  modifications.  This  type  of  application  will  work  similar  to  a  web 
search  engine  and  the  unit  phone  book.  A  user  can  use  search  engine  technology  within 
the  application  to  type  in  equipment  nomenclatures,  titles,  or  any  other  information  known 
to  track  a  specific  piece  of  equipment  to  produce  a  listing  of  all  matching  resources.  The 
listing  will  then  provide  a  detailed  summary  of  the  organization  and  person  associated  with 
that  piece  of  equipment  and  how  they  relate  to  ESU  Alameda.  The  user  then  matches 
their  current  operational  need  against  the  list  of  resources  until  a  match  is  found.  The  list 
can  be  shared  and  maintained  by  everyone  using  it,  so  as  changes  occur,  they  only  need  to 
be  updated  once  to  make  it  beneficial  to  the  entire  command.  The  use  of  the  application 
wall  continually  evolve  as  people  enter  more  and  more  information  into  the  system.  This 
type  of  application  wall  help  reduce  the  time  required  to  bring  new  personnel  up  to  speed 
and  minimize  the  command  pains  associated  with  loosing  25%  of  the  crew  each  summer 
during  the  annual  transfer  season. 
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7.  Operating  Instructions,  Personnel  Manuals,  Newsletters,  and 
Orientations 

The  use  of  web  based  personnel  manuals,  operating  instructions,  newsletters, 
orgamzational  charts  and  orientations  will  enable  personnel  to  quickly  become  acclimated 
with  command  procedures.  Orientations  on  command  history,  operating  procedures,  and 
accomplishments  can  be  used  to  mold  the  new  personnel  into  the  desired  culture  of  the 
command.  As  mission  goals  change,  this  application  will  enable  the  quick  modifications  to 
business  policies.  In  addition,  the  use  of  a  web-based  application  will  help  mold  mental 
models  and  instill  group  learning  as  organizational  changes  are  required  by  using  media 
which  is  more  impacting  than  written  text  alone.  Currently  over  100  manuals  are 
published  and  distributed  biannually  to  organizations  supported  by  ESU  Alameda  to  offer 
guidance  and  procedures.  However,  ESU  Alameda  has  no  guarantee  that  the  current 
versions  of  these  manuals  are  made  available  to  the  key  members  ESU  Alameda  interacts 
with.  This  creates  a  burden  for  both  ESU  Alameda  and  the  key  members  of  the  supported 
commands.  By  using  a  web-based  application,  every  individual  with  a  computer  and 
intranet/extranet  access  will  be  able  to  interact  with  the  most  current  ESU  publications 
available.  Therefore,  not  only  will  this  application  enhance  the  learning  environment  of  the 
ESU  employees,  but  it  will  also  enable  better  distribution,  reductions  in  biannual 
pubhshing  and  distribution  fees,  and  access  to  current  information  by  those  commands 
supported  by  ESU  Alameda. 
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8.  Newsgroups 

The  use  of  a  newsgroup  application  by  the  ESU  employees  would  enable  them  to 
solicit  information  and  keep  abreast  of  technology  changes  with  the  rest  of  the  world.  In 
addition,  internal  newsgroups  could  be  established  and  made  available  to  employees  or 
other  Coast  Guard  organizations.  Since  any  post  to  a  newsgroup  outside  the  organization 
will  have  a  military  extension  on  it,  strict  command  policy  must  be  implemented  governing 
the  types  of  groups  which  are  accessible  and  the  extent  of  information  which  will  be 
exchanged.  Since  the  use  of  internal  newsgroups  are  proprietary,  the  security  aspects  are 
much  less  complex  and  easier  to  implement  and  enforce.  For  this  reason,  ESU  Alameda 
may  want  to  only  use  internal  newsgroups,  or  restrict  access  to  these  groups  to  only 
selected  Coast  Guard  Commands. 

9.  Customer  Knowledge  Base 

Coupled  with  the  large  turnover  rates  associated  with  military  transfers,  unique 
operational  requirements,  and  ESU  Alameda’s  extensive  need  to  collaborate  with 
multitudes  of  organizations,  some  form  of  knowledge  base  needs  to  exist  to  help  personnel 
locate  technical  information  about  supported  commands.  For  example,  a  typical  ESU 
supports  several  classes  of  ships,  each  with  different  equipment  and  different  engineering 
parameters.  Some  of  these  organizations  have  unique  challenges  such  as  electronic  power 
or  grounding  problems,  cable  access  challenges,  or  anteima  location  constraints  to  name  a 
few.  This  makes  it  difBcult  for  any  remote  personnel  to  plan  future  installations,  forecast 
engineering  challenges,  or  simply  offer  technical  assistance  since  each  class  of  ship  is  so 
unique.  However  the  use  of  a  customer  knowledge  based  application  would  enable  a  user 
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to  search  out  needed  information  on  a  specific  Coast  Guard  unit,  and  receive  details  such 
as  wiring  diagrams,  photographs,  known  problems,  archived  repairs,  and  past  engineering 
studies.  In  addition,  existing  fault  parameters  could  be  input  to  the  application  and 
assistance  provided  on  probable  causes.  However,  the  development  and  maintenance  of 
such  an  application  would  be  enormous  and  beyond  the  capabilities  of  ESU  Alameda. 
Nevertheless,  it  would  be  of  immense  help  and  could  be  linked  to  a  headquarters 
application  to  enable  additional  engineering  and  maintenance  research. 

10.  Military  Transfer  Knowledge  Base 

With  the  average  ESU  member  transferring  every  three  to  four  years,  an 
application  to  assist  personnel  plan  for  these  moves  would  benefit  morale  and  reduce  the 
current  planning  time  required  by  Coast  Guard  Emilies.  Currently,  manuals  are  published 
listing  all  billets  in  the  Coast  Guard,  however,  these  manuals  become  outdated  the  minute 
they  are  published.  To  inform  Coast  Guard  personnel  which  billets  are  to  be  vacated  and 
made  available  for  selection.  Coast  Guard  members  can  have  information  sent  to  them  by 
means  of  a  multiple  page  facsimile.  However,  these  sheets  are  often  difficult  to  read  and 
offer  little  insight  into  the  requirements  of  the  job  and  offerings  of  the  community 

Development  and  maintenance  of  a  web-based  application  by  Coast  Guard 
Headquarters  and  used  within  the  ESU  Alameda  intranet  would  allow  access  to  current 
billet  descriptions,  rotation  dates,  phone  numbers,  and  skill  requirements,  as  well  as 
community  mformation,  housing,  schools,  and  points  of  interest.  To  accommodate  special 
femily  needs  such  as  medical  or  school  challenges,  a  knowledge  based  application  would 
interact  with  the  user  to  locate  possible  openings  which  meet  those  specified  requirements. 


69 


This  type  of  application  would  mirror  with  current  Coast  Guard  Work-Life  initiatives, 
reduce  stress  levels  associated  vdth  moving,  increase  morale,  and  reduce  some  of  the  time 
management  challenges  currently  plaguing  program  managers  in  negotiating  possible 
transfers  with  Coast  Guard  members. 

1 1 .  Customer  Request,  Measurement,  and  Report  Generation 

Currently  ESU  Alameda  customers  request  assistance  through  means  of  radio 
broadcast  message  traffic,  phone  calls,  personal  visits,  or  email.  To  conform  to  Coast 
Guard  measurement  guidelines  as  well  as  focusing  on  command  effectiveness,  designated 
ESU  employees  track  and  measure  open  requests,  contracted  performance,  and  funding 
information  for  compilation  and  generation  of  monthly  reports.  Since  there  are  no  ESU 
billets  authorized  for  this  function,  these  tasks  are  assigned  as  collateral  duties  to  several 
ESU  employees.  Although  this  provides  many  positive  aspects  for  the  command  it  also 
reduces  the  available  time  of  the  technicians  and  crew.  For  this  reason  the  available  time 
for  workloads  is  more  reactive  to  equipment  failures  than  proactive  in  preventive 
maintenance  and  planning.  A  web  based  application  would  automate  some  of  these  tasks 
and  enable  ESU  employees  to  better  utilize  their  available  time.  In  addition,  online 
generation  of  these  reports  would  reduce  the  costs  associated  with  publishing  and 
distribution  and  enable  real-time  feedback  to  organizations  needing  this  information. 
Additional  functionality  could  be  added  to  this  application  by  linking  it  with  the  supply 
tracking  system.  Coupled  together,  these  two  applications  could  build  a  knowledge  base 
capable  of  forecasting  and  graphing  workloads,  budget  requirements,  and  supply  ordering 
requirements  for  each  supported  platform  on  a  calendar  basis.  Such  a  system  would 
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significantly  aide  the  organization  in  scheduling  future  projects,  leave  request,  quarterly 
budget  distributions,  and  just  in  time  training  requirements. 

12.  Training 

ESU  Alameda  currently  performs  several  types  of  specialized  training  for  such 
things  as  new  personnel  indoctrination,  new  application  famiharization,  or  to  establish 
specialized  skills  for  an  upcoming  project.  To  facilitate  this  training  and  enable  just  in  time 
learning,  a  web-based  application  could  be  established  and  interactively  used  as  needed. 
This  application  could  be  requested  by  the  needing  user  anytime,  therefore  eliminating 
existing  scheduling  conflicts  between  the  trainer  and  trainees.  Using  brochures,  video,  and 
internally  generated  PowerPoint  presentations,  almost  any  type  of  training  presentation 
could  be  accomphshed.  If  hands-on  training  is  required,  the  development  of  a  training 
kiosk  may  offer  more  interaction  with  the  training  platform.  Although  some  specialized 
training  may  require  professional  development,  many  of  the  training  tasks  associated  with 
annual  certification  and  project  preparations  could  be  developed  by  ESU  Alameda. 

E.  CONCLUSION 

This  chapter  addressed  the  potential  functionality  of  the  ESU  Alameda  intranet  by 
providing  a  brief  review  on  the  types  of  applications  typically  used  within  corporate 
intranets,  and  offering  suggestions  for  military  apphcation  development.  The  majority  of 
the  chapter  focused  on  applications  which  would  offer  significant  improvements  to  the 
current  business  processes  of  ESU  Alameda. 
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Now  that  the  reader  can  visualize  the  complexity  of  the  various  applications  that 
would  make  up  an  ideal  ESU  intranet  system,  the  design  of  the  baseline  intranet  focusing 
on  administrative  issues  and  data  analysis  of  the  supply  tracking  system  will  be  presented 
in  the  next  chapter.  ESU  Alameda  may  wish  to  review  chapter  five  as  time  goes  on  to 
consider  fiature  development  considerations  above  that  presented  in  the  next  two  chapters. 
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VL  ANALYSIS  OF  CLIENT’S  BUSINESS  PROCESSES 


A.  INTRODUCTION 

Since  Data  Flow  Diagrams  (DFDs)  are  one  of  the  most  widely  used  tools  for 
modeling  business  processes,  they  will  be  used  within  this  thesis  to  analyze  the  functional 
activities  of  ESU  Alameda.  To  enable  the  reader  to  follow  this  analysis,  the  chapter  will 
start  with  a  brief  history  on  database  functionality.  Followed  by  an  overview  of  DFD 
symbols  and  implied  rules.  After  presenting  the  required  background  material,  the 
remainder  of  the  chapter  will  present  the  DFDs  derived  for  the  ESU  Alameda  Business 
model,  offering  insight  to  current  business  practices  and  enabling  a  visionary  look  at  what 
post  intranet  implementation  may  achieve. 

B.  fflSTORY 

Databases  are  categorized  by  the  way  they  maintain  data  relationships  [Ref  23, 
p.  15],  Early  databases  were  nothing  more  than  flat  file  systems  that  allowed  a  user  to 
archive  information  and  serve  as  electronic  filing  cabinets.  Due  to  the  very  nature  of  this 
type  of  database,  it  typically  led  to  data  redundancy,  which  is  the  saving  of  redundant 
information  on  different  databases.  As  a  result  of  data  redundancy,  the  data  itself  becomes 
difiBcult  to  maintain  and  is  usually  inaccurate  in  at  least  one  of  the  databases  used. 
However,  since  the  1960's  major  changes  in  database  design  have  been  made  to  help 
correct  this  problem. 

The  1980's  brought  about  the  use  of  relational  databases  which  significantly 
improved  the  management  of  data,  reducing  data  redundancy.  Data  stored  in  one  table 
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could  now  update  many  other  tables  or  databases  through  shared  resources.  In  addition, 
access  to  these  tables  could  now  cross  several  types  of  database  platforms.  For  example, 
Microsoft  Access  could  now  read  and  write  to  a  database  written  in  dBase  or  Paradox. 
For  database  users  this  was  a  revolutionary  accomphshment  because  developers  were  now 
able  to  use  data  already  located  in  various  databases  rather  than  recreating  the  data 
themselves.  Figure  6.1  offers  a  good  overview  of  the  features  and  technological  changes 
that  have  occurred  in  database  design. 
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Figure  6.1  Evolution  of  Database  Architectures,  [Ref.  23,  p.  16] 
C.  PROCESS  MODELING 


Process  Modeling  is  used  by  designers  to  gain  an  understanding  of  what  is 
occurring  within  an  organization.  By  using  such  a  graphical  interpretation  of  the 
processes  involved  an  organization’s  business  model  can  be  understood. 
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An  effective  diagram  has  two  primary  functions:  it  records  and 
communicates.  The  effectiveness  of  a  diagram  is  contingent  on  its  clarity 
and  completeness.  No  matter  how  accurate  a  diagram  is,  if  the  information 
it  contains  is  not  easily  understood  by  its  user,  it  is  practically  useless 
[Ref  24,  p.  1]. 

This  concept  is  the  basis  for  the  development  mid  use  of  Data  Flow  Diagrams 
(DFDs).  Therefore,  DFDs  are  primarily  used  to  clarify  information  flow  within 
organizations,  to  locate  redundancies,  and  to  determine  the  requirements  of  the 
organization.  Although  there  are  several  different  modeling  tools  available,  the 
advantages  with  using  DFDs,  is  that  there  is  only  one  set  of  rules  and  only  four  symbols 
used  to  represent  the  data  flow.  Figure  6.2  will  enable  the  reader  to  translate  the 
associative  meaning  of  the  two  common  DFD  symbol  sets  currently  in  use: 


Figure  6.2 

Comparison  of  DeMarco  and  Yourdan  and  Gane  &  Sarson  DFD  symbol  sets, 

[Ref.  25,  p.  315] 
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Regardless  which  DFD  symbol  set  is  used,  a  defined  and  common  set  of  rules  are 
used  to  add  meaning  to  the  analysis.  Since  these  rules  are  implied,  the  reader  must 
understand  them  before  reviewing  the  ESU  Alameda  DFDs  if  proper  analysis  is  to  be 
interpreted.  For  this  reason,  a  brief  explanation  for  the  use  of  the  four  symbols  will  be 
presented,  and  then  followed  by  the  rules  associated  with  their  use.  A  description  of  the 
four  symbols  represent  in  a  DFD  are  as  follows; 

1.  Process:  The  work  or  actions  performed  on  data  so  that  they  are 
transformed,  stored,  or  distributed. 

2.  Data  Store:  Data  at  rest,  which  may  take  the  form  of  many  different 
physical  representations  (i.e.  a  file  folder,  notebook). 

3.  Source/sink:  The  origin  and/or  destination  of  data  sometimes  referred 
to  as  external  entities. 

4.  Data  flow:  Shows  the  direction  that  data  is  flowing  through  a  system 
[Ref  25,  p.  315]. 

As  previously  mentioned,  the  use  of  DFDs  is  simplified  by  the  small  symbol  set  and 
single  set  of  implied  rules.  This  feature  enables  analyst  to  share  their  DFDs  with  many 
different  designers  without  the  need  of  written  details.  Just  like  the  phrase  “a  picture  is 
worth  a  thousand  words”  the  DFDs  tell  the  story  which  may  otherwise  be  misinterpreted 
in  written  context.  To  enable  the  reader  to  understand  the  ESU  Alameda  DFDs  which  will 
be  presented  later  in  this  chapter,  the  DFD  rules  will  be  presented  in  an  easy  to  access 
format  suitable  for  quick  reference  later  on.  These  rules  are  as  follows; 

Entities 

♦  Relationships  between  Entities  are  not  modeled 

♦  Entities  never  communicate  directly  with  data  stores 
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♦  Entities  are  always  named  using  a  noun  label 

♦  Changes  to  Entities  can  only  occur  through  data  interchange  with  the  Main 
Process. 

Processes: 

♦  Processes  are  always  named  in  a  verb  phrase  label 

♦  Processes  may  be  done  in  parallel 

When  working  with  Processes,  you  should  avoid  the  following: 

♦  Black  Holes.  A  process  with  only  inputs.  See  Figure  6.3 
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Figure  6.3  Black  Hole 


♦  Miracles'.  A  process  with  no  inputs  and  only  outputs.  See  Figure  6.4 


0 

Intranet 

Process 

V _ > 

Various 

Output 

Figure  6.4  Miracle 
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♦  Grey  Hole:  Insufficient  inputs  to  produce  the  outputs.  See  Figure  6.5 
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Figure  6.5  Grey  Hole 


Data  Store: 

♦  Data  cannot  be  interchanged  between  other  data  stores.  The  data  must  pass 
through  a  process  initially 

♦  Data  Stores  do  not  change  (process)  any  data 

♦  Processes  are  always  named  using  a  noun  label 

♦  Data  Stores  may  be  repeated  on  a  diagram 
Data  Flow: 

♦  Data  flows  are  drawn  in  one  direction  between  processes.  If  data  is  Bi¬ 
directional,  two  data  flows  must  be  drawn. 

♦  A  Data  flow  to  a  Data  Store  means  Update 

♦  Data  flow  fi-om  a  Data  Store  means  Retrieve 

♦  Processes  are  always  named  using  a  noun  label 

DFDs  are  hierarchical  by  design.  By  this  we  mean  the  Context  Level  diagram  is 
the  parent  and  is  the  highest  level  diagram  possible,  showing  the  an  entire  organization  as 
one  process.  When  viewing  this  diagram,  the  user  will  be  able  to  see  those  entities 
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external  to  the  organization  that  interact  with  the  main  process  by  the  transfer  of 
information.  Decomposition  of  the  Context  Level  diagram  is  used  to  obtain  child,  or 
lower  level  DFDs.  When  doing  this,  the  decomposition  of  the  Context  Level  diagram 
leads  to  a  Level  0  diagrams  with  a  numbering  convention  of  1.0,  2.0,  3.0...X.0.  Further 
decomposition  of  these  processes  lead  to  Level  1  diagrams  that  follow  the  numbering 
convention  of  1.1,  2.1,  3.1...X.1.  This  decomposition  of  a  processes  can  continue  until 
the  primitive,  or  lowest  level  DFD  is  obtained.  When  looking  at  the  entire  numbering 
convention  used,  typical  numbers  for  lower  level  diagrams  could  be  as  follows:  1.1.1, 
1.1.2,  etc. 

Balancing  DFDs  is  essential  for  accuracy  and  is  defined  as  the  conservation  of 
inputs  and  outputs  to  a  data  flow  diagram  process  when  the  process  is  decomposed  to  a 
lower  level  [Ref.  25,  p.  324].  This  means  that  as  the  diagrams  are  further  decomposed  the 
input  and  outputs  associated  with  a  given  process  must  be  accounted  for  throughout  the 
Child  and  Parent  relationships. 

D.  ANALYSIS  PHASE  USING  DATA  FLOW  DIAGRAMS 

As  previously  mentioned  in  chapter  four,  data  was  gathered  fi-om  ESU  Alameda  by 
obtaining  various  forms  and  publications  as  well  as  conducting  individual  and  group 
interviews.  During  the  interviewing  process  the  functionality  of  various  forms  was 
determined  and  compared  against  the  business  models  of  the  organization.  Of  all  the 
forms  collected,  it  was  determined  that  four  actually  applied  to  the  business  model  this 
team  was  asked  to  improve  and  therefore  analyzed  for  intranet  implementation.  These 
forms  included  the  supply  Procurement  Request  form.  Bill  of  Lading  form.  Requisition 
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Log  (SURF  Sheet),  and  the  administrative  standard  Leave  Request  form.  In  addition,  the 
team  decided  to  include  additional  administrative  data  on  the  intranet  because  of  its  related 
use  and  similarity  of  development.  This  data  includes  the  Command  Phone  Book, 
Temporary  Additional  Duty  (TAD)  log,  and  crewmember  directories. 

To  accommodate  all  of  this  information  without  sacrificing  security  the  intranet 
was  developed  in  two  sections.  The  secure  section  was  termed  the  intranet,  while  the  less 
secured  area  was  termed  extranet. 

A  full  service  Intranet  is  a  TCP/IP  network  inside  a  company  that  links  the 
people  and  information  in  a  way  that  makes  people  more  productive, 
information  more  accessible,  and  navigation  through  all  the  resources  and 
applications  more  seamless  than  ever  before  [Ref  23,  p.  57]. 

The  extranet  provides  some  of  the  same  information  as  the  intranet  but  is  not 

subject  to  all  of  the  security  and  privacy  aspects  desired  in  a  corporate  intranet.  Without 

an  additional  security  measure  such  as  a  firewall,  the  extranet  is  accessible  to  anyone  who 

has  access  to  the  internet  and  the  correct  Uniform  Resource  Locator  (URL)  or  internet 

address. 

Throughout  the  analysis  of  data,  emphasis  was  placed  on  redesigning  the  business 
process  and  not  simply  automating  it.  By  simplifying  these  transactions  with  the  use  of 
DFDs,  redundancy  was  identified  and  data  integrity  increased.  Although  we’ve  explained 
data  redundancy,  we  need  to  examine  data  integrity.  Data  Integrity  refers  to  the  ability  of 
the  distributed  database  to  manage  concurrent  updates  to  data  in  many  physical  locations 
and  ensure  that  all  of  the  data  is  physically  and  logically  correct  [Ref  26].  Therefore,  by 
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reducing  data  redundancy  and  increasing  data  integrity  the  overall  accuracy  of  the  system 
will  increase. 

Many  simple  administrative  tasks  such  as  filling  out  a  Leave  Request  or  Parts 
Ordering  require  many  steps  and  man-hours  to  route  paperwork  through  an  inefficient 
system.  Therefore,  one  of  the  goals  of  this  thesis  will  be  to  reduce  the  time  and  effort 
involved  in  completing  a  task. 

This  remainder  of  this  chapter  presents  the  DFDs  developed  for  both  current  and 
new  business  processes  selected  for  intranet  application.  The  applications  that  were  not 
used  on  the  intranet  but  were  evaluated  at  length  are  included  in  Appendix  B.  Detailed 
explanations  of  the  process  interactions  within  the  current  business  model  are  included  in 
Appendbc  C. 

1.  Existing  Business  Models 

Figure  6.6  shows  the  current  business  model  for  the  Leave  Request  process.  A 
person  requests  leave  through  the  process  and  gains  approval  fi'om  immediate  supervisors. 
Upon  approving/disapproving  the  leave  request  the  form  is  routed  to  the  Executive  Officer 
who  provides  final  approval/disapproval  for  the  requested  leave. 

The  Leave  Request  process  is  further  decomposed  in  Figure  6.7.  Here  the  leave 
request  is  filled  out  and  the  leave  form  is  routed  fi'om  supervisor  to  supervisor.  Upon  final 
approval/disapproval  the  request  form  is  sent  back  to  the  originator. 
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Figure  6.6  Context  Level  DFD  -  Leave  Request 
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-LeaveRsquest- 


-SupCTvisor  1  Leave  ApprovalorDeniat 
-Supervisor  2  Leave  Approvalor  Deniat 
- ^FinalLeaveApprovalorDeniat 
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Leave 

Information 


InMRequest 


Leave  Approved  or  Denied - ► 

Approved  Leave  Request - ► 

Secondary  Approval - ► 


Figure  6.7  Level  1 DFD  -  Leave  Request 

Figure  6.8  presents  a  good  example  of  how  a  process  was  automated  without 
adding  any  functionality  to  the  system.  Even  though  the  leave  form  is  input  into  an 
automated  system,  by  email,  the  status  updates  and  retrieval  of  archived  information  is 
performed  manually  and  may  actually  take  more  time  to  perform  than  the  previous  paper 
method.  For  example,  when  the  paper  version  was  filed  there  existed  a  filing  scheme. 
With  the  use  of  email,  the  location  and  sequence  of  a  request  is  unknown  and  could  be 
located  in  several  different  locations. 


83 


Online  Leave 
Information 


> 


2.1 


Submit 
Leave  Form 


Form 

Data 


2.2 


-Initial  Request- 


E-Mail 
Notification, 


-Secondary  Approval 


“improved  Leave  Request-^ 


EMail 

Data 


-Supervisor  1  Leave  .^)proval  or  Denial^j' 
-Supervisor  2  Leave  y^jproval  or  Denial 
- Final  Leave  >^>proval  or  Denial — ►! 


Status 

Notification 


Monitor 

Status 


Leave 

Database 


-Leave  Approved  or  Denied—^ 


Figure  6.8  Level  1  DFD  -  Leave  Request 
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Figure  6.9  presents  the  Context  Level  diagram  for  the  current  Parts  Ordering 
System.  The  function  of  the  Parts  Ordering  process  is  to  act  as  focal  point  for  all  of  the 
command's  part  requests,  including  budget  verification,  quality  control,  ordering,  tracking 
forecasting,  and  transportation  of  materials.  This  process  is  the  cornerstone  to  making 
the  command  operate  efficiently  and  is  the  number  one  request  of  the  command  to  attempt 
to  resolve  inefficiencies  within  the  system. 
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- ^Feedback- 

- Completed  Order 
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Figure  6.9  Context  Level  Diagram  -  Parts  Ordering 
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The  Parts  Ordering  System  is  further  decomposed  in  Figure  6. 10.  As  can  be  seen 
in  this  data  flow  diagram,  the  ordering  a  single  part  becomes  a  very  complex  and  time 
consuming  evolution.  There  is  a  minimum  of  eight  different  processes  that  the  requested 
part  must  go  through  before  it  can  be  completed.  Delays  are  introduced  by  the  processes 
themselves  as  well  as  the  way  information  is  passed.  In  this  case,  most  paperwork  must  be 
physically  "walked"  to  the  next  process. 

Since  ESU  Alameda  heavily  relies  on  the  timely  processing  of  parts  request  to 
repair  electronics  equipment,  a  means  to  make  this  system  more  efficient  is  clearly  in  need. 
In  addition,  the  Storekeeper  is  currently  overworked,  spending  more  than  25%  of  the 
average  day  tracking  dovm  the  various  stages  of  these  processes.  Therefore,  developing 
an  intranet  based  system  capable  of  improving  the  existing  business  model  will  have 
notable  impact  for  all  members  of  the  command,  a  feature  which  is  needed  to  enable  the 
successful  acceptance  of  the  intranet  and  new  business  model.  Because  this  resolution  of 
this  process  is  requested  by  the  command  and  is  determined  to  benefit  every  user  of  the 
organization,  deriving  a  better  business  model  became  one  of  the  top  objectives  of  this 
project. 


86 


Figure  6.10  Level  O  DFD  -  Parts  Ordering  System 
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2.  Intranet  Based  Business  Models 


Figure  6.11  through  6.19  presents  the  redesigned  business  models  enabled  by  the 
ESU  Alameda  intranet.  These  new  processes  allow  a  one-stop  location  to  accomplish  in 
minutes  or  hours  what  used  to  take  hours,  days,  or  even  weeks  to  accomplish.  The 
intranet  based  design  depicts  a  well  thought  out  approach  that  is  extremely  user  friendly. 

It  is  the  intent  of  the  design  team  to  reduce  the  required  work  efforts  and  times  by 
centralizing  all  of  the  Administrative  and  Supply  tools  in  one  location.  As  can  be  seen  in 
Figure  6.11,  there  is  a  central  point  for  users  to  enter  the  intranet  to  accomplish  these 
tasks. 


Request  Extranet  ^ 
Information  ^ 

External  Users  ^  , 

1.^ — Requested  ExtranetJ 
'  Data  ' 


t  Requested  Eitranc^ 
Data  ^ 

— Request  Intranet-] 
Information 


Figure  6.11  Context  Level  DFD  -  ESU  Intranet  Processes 

Once  the  user  enters  the  main  interface,  the  user  has  the  choice  to  access  the 
Member  or  Public  sections  as  portrayed  in  Figure  6. 12.  To  enter  the  Public  area  the  user 
simply  selects  the  extranet.  There  is  no  requirement  to  log  into  an  unsecured  area.  To 
access  the  intranet  all  users  must  login  with  an  authorized  user  name  and  password.  Upon 
successful  login  the  user  enters  the  Member's  area  where  secure  information  is  kept.  If  the 
log  in  is  unsuccessful  they  are  returned  to  the  main  screen. 
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Figure  6.12  Level  O  DFD  -  ESU  Intranet  Processes 


Decomposing  Process  4  to  the  next  level  allows  access  to  limited  resources  on  the 
extranet  as  shown  in  Figure  6.13.  At  this  level  there  is  access  to  multiple  resources,  such 
as  FAQ's,  what’s  new  on  the  intranet,  and  access  to  the  unit  phonebook.  Process  4.2 
allows  access  to  the  unit  phonebook. 
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Figure  6.13  Level  1  DFD  -  Select  Extranet  Application 


Process  4.1  is  further  decomposed  in  Figure  6.14.  Within  this  process,  process 
4.3.4  enables  additional  menus  options  to  the  user  such  as  Suggestions,  Chat  Room,  and 
intranet  wide  search  capabilities. 
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Figure  6.14  Level  2  DFD  -  Query  Help  Section 

Process  3.1  is  the  Level  1  DFD  for  Process  3  of  Figure  6.12.  This  Process  allows 
the  option  of  entering  the  Supply  or  Administrative  areas  of  the  intranet. 


Figure  6.15  Level  1  DFD  -  Select  Intranet  Application 
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Figure  6.16  reveals  the  Processes  that  encompass  the  Supply  Section  of  the 
intranet.  Process  3.3.2  allows  any  of  three  forms  to  be  filled  out  online,  read  the  database 
warning,  or  exit  to  the  main  menu.  Screen  shots  of  the  four  forms  will  be  provided  in 
chapter  7. 
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Figure  6.16  Level  2  DFD  -  Select  Supply  Applications 
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Figure  6.17  presents  the  processes  that  encompass  the  Administrative  Section  of 
the  intranet.  Process  3.2.2  allows  access  to  either  Administrative  Reports  or 
Administrative  Forms. 
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Figure  6.17  Level  2  DFD  -  Select  Administrative  Applications 


Figure  6.18  allows  the  user  to  view  any  of  four  reports  online.  These  are  dynamic 
reports  and  are  enabled  through  the  processes  in  Figure  6.19.  Reports  are  also  available  at 
demarcations  of  thirty  and  sixty  days  prior  to  going  TAD  or  on  leave.  This  information  is 
essential  for  command  planning  purposes  and  relinquishes  time  spent  by  managers  and 
supervisors  in  tracking  this  information. 
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Figure  6.18  Level  3  DFD  -  Select  Administrative  Reports 


Figure  6.19  allows  users  to  select  online  forms.  In  this  Data  Flow  Diagram, 
Process  3.2.3.2  enables  the  person  who  filled  out  a  leave  request  to  monitor  its  status 
without  requiring  time  consuming  research  of  supervisors  and  managers.  As  the  leave 
request  advances  through  the  system,  annotations  approving  or  disapproving  the  request 
will  be  added.  This  allows  for  instant  response  and  monitoring.  In  similar  fashion. 
Process  3. 2. 3. 3  allows  the  user  to  request  TAD  orders  online.  Both  of  these  processes  are 
capable  of  being  updated  at  anytime.  Leave  or  TAD  requests  are  archived  for  future  use 
to  allow  for  historical  tracking. 
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Figure  6.19  Level  3  DFD  -  Select  Administrative  Reports 


The  complexity  of  the  new  business  model  is  overshadowed  by  the  ease  of  access 
to  all  information.  The  use  of  the  DFDs  presented  in  this  section  illustrate  that  ESU 
business  processes  can  be  changed  and  unproved.  For  this  case,  change  is  not  made  for 
the  sake  of  change,  but  as  an  effective  tool  in  obliterating  old  business  practices  to 

improve  efficiency  and  command  productivity. 

The  CASE  tool  used  to  design  the  DFDs  for  this  thesis  was  Visible  Analysts 
Workbench  Student  Edition,  Version  6.0a.  The  symbol  set  used  in  the  design  of  the 
DFD's  was  Gane  &  Sarson.  The  DFD's  were  decomposed  to  their  lowest  level  and 

balanced. 
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E.  CONCLUSION 


This  chapter  provided  a  brief  history  of  the  database  evolution  and  the  knowledge 
required  to  understand  data  flow  diagrams.  The  diagrams  included  within  this  chapter 
depicted  a  transition  from  individual  processes  under  the  current  business  model  to  a  fully 
integrated  intranet  based  process  utilizing  the  business  model  developed  as  part  of  this 
thesis.  Security  aspects  of  the  intranet  were  briefly  described  and  will  be  presented  in 
more  detail  in  chapter  8,  the  conclusion  of  this  thesis.  As  a  reminder,  all  additional  DFDs 
for  processes  not  incorporated  into  the  intranet  are  provided  in  Appendix  B  for  future 
development  considerations. 
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Vn.  INTRANET  DESIGN 


A.  INTRODUCTION 

This  chapter  will  explain  the  importance  of  the  graphical  user  interface  and 
present  various  screenshots  for  the  ESU  Alameda  intranet  design  specification.  It  will 
explain  how  the  use  of  iterative  database  designs  enabled  a  development  that  met  the 
business  models  established  in  chapter  six.  Several  screen  shots  are  included  to  enable 
the  reader  to  understand  the  uses  of  this  rapid  prototype  development  effort. 

B.  INTERFACE  DESIGN 

To  this  point  the  readers  have  been  introduced  to  several  potential  intranet 
applications  (chapter  five),  as  well  as  analysis  of  pre  and  post  intranet  business  models 
(chapter  six).  However,  it  should  be  understood  that  these  applications  would  not  enable 
the  success  of  the  proposed  business  models  without  the  use  of  a  well-defined  graphical 
interface.  For  without  the  use  of  an  interface  that  is  easily  navigated  and  intuitively 
understood,  the  users  will  reject  the  intranet  concept  and  the  new  business  model  would 
fail  Therefore,  the  conceptual  design  of  a  robust  graphical  user  interfece  became  another 
primary  design  consideration  for  this  project. 

In  defining  the  interface  requirements  and  humanistic  feel  for  the  ESU  Alameda 
intranet,  the  team  evaluated  several  web  sites  known  to  distribute  information.  After 
researching  several  possibilities,  the  team  was  inspired  through  use  of  a  proven 
commercial  web  site  at  http://mv.excite.com,  and  decided  to  use  this  philosophy  to  pass 
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daily  information  within  the  ESU  Alameda  intranet.  The  team  then  placed  emphasis  in 
designing  a  user-friendly  interface  that  maintained  the  following  attributes: 

♦  Utilizes  a  point  and  click  interface 

♦  Provided  timely  and  informative  information 

♦  Consistent  "Home  Page"  look  and  feel 

♦  Speed  when  loading  pages 

♦  Simplicity  and  familiarity  when  navigating 

This  concept  was  achieved  by  starting  all  users  on  the  intranet  "home  page"  when 
they  initially  logged  onto  the  intranet.  At  this  location,  the  user  is  able  to  quickly  assess 
the  operational  state  of  the  command  by  merely  glancing  the  descriptive  hypertext  titles 
on  the  screen.  If  detailed  information  were  desired,  it  would  be  obtained  by  clicking  on 
title.  By  composing  the  descriptive  titles  onto  one  page  and  forcing  the  users  to  start  at 
this  location,  the  command  is  guaranteed  all  users  are  exposed  to  the  command’s  critical 
information  each  time  the  intranet  is  accessed. 

The  consistent  look  of  the  intranet  was  achieved  by  displaying  the  left  frame  at  all 
times.  This  is  made  possible  during  the  initial  download  of  the  intranet  site  where  the  left 
frame  is  stored  in  cache  memory.  By  maintaining  a  consistent  left  frame,  both  doAvnload 
speed,  simplicity,  and  familiarity  are  achieved.  The  consistent  left  frame  also  allows  the 
user  to  select  alternate  applications  within  the  intranet  at  any  time.  The  right  frame  will 
display  the  newly  selected  information.  This  can  be  seen  later  in  this  chapter  as  various 
online  forms  are  displayed  where  the  left  frame  is  static  and  the  right  frame  is  dynamic. 
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C.  INTRANET  SOLUTIONS 


By  analyzing  the  new  business  models  in  chapter  six,  along  with  some  of  the 
ideas  used  at  http://mv.excite.com  web  site,  a  baseline  for  the  intranet’s  design  can  be 
seen.  For  example,  the  Data  Flow  Diagram  in  Figure  6.11  enabled  the  old  business 
process  to  be  transformed  into  the  opening  screen  shot  for  the  Intranet  in  Figure  7. 1 .  This 
enabled  the  command  at  ESU  Alameda  to  be  able  to  retrieve  important  statistical  facts  at 
a  moment's  notice.  This  would  create  a  new  way  of  doing  business,  as  the  information 
would  be  virtually  real  time.  Items  of  interest  provided  on  the  opening  screen  of  the 
Intranet  are; 

♦  General  announcements 

♦  Leave  Summary 

♦  Personnel  on  Temporary  Additional  Duty  (TAD) 

♦  Plan  of  the  Week 

As  mentioned  in  chapter  4,  this  project  was  developed  conjointly  as  a  three- 
member  teaml.  This  chapter  highlights  the  Intranet  solution  with  the  emphasis  being 
placed  on  the  database  solutions. 


'  LT  Rail*  Benhart  and  LT  Dean  Dardis  comprised  the  Supply  Tracking  System  team  and  developed  this 
thesis  using  Microsoft  Access  for  the  specification  development  tool,  while  LT  Todd  Hannah  comprised 
the  Personnel  Administration  team  and  developed  a  separate  thesis  using  Microsoft’s  Active  Server 
Scripting  as  the  specification  development  tool. 
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To  facilitate  the  use  of  the  new  supply  and  personnel  tracking  systems  where 
responsibilities  are  pushed  to  the  lowest  level,  several  familiar  forms  must  be  introduced 
on  the  intranet.  However,  unlike  the  use  of  the  old  paper  forms  which  required  a  large 
amount  of  Storekeeper  or  Administrative  involvement,  the  new  automated  forms  with 
pull  down  combination  boxes  will  enable  responsibilities  to  be  pushed  to  the  lowest  level 
in  the  command.  The  required  forms  are  as  follows: 

♦  Supply  Procurement  Request  form 

♦  Bill  of  Lading  form 

♦  Requisition  Log  (SURF  Sheet), 

♦  Leave  Request  form. 

Figure  7.2  presents  the  online  Leave  Request  form.  By  enabling  the 
crewmembers  of  ESU  Alameda  to  fill  out  Leave  Request  online,  not  only  the  member, 
but  also  the  command  is  able  to  keep  track  of  all  personnel  requesting  leave.  This  leave 
form  provides  a  central  location  to  monitor  the  status  of  a  request.  This  application 
abolishes  the  old  slow  and  an  ineffective  practice  of  updating  and  tracking  leave  status 
and  replaces  it  with  an  automatic  and  very  efficient  central  repository. 

This  new  form  will  aid  in  the  tracking  of  leave  requests  as  well  as  planning  for 
future  duty  assignments  at  the  unit.  As  the  leave  is  submitted  up  the  chain  of  command 
and  approved  or  disapproved,  emails  are  automatically  forwarded  to  the  person 
requesting  the  leave.  This  provides  real  time  notification  as  to  the  status  of  the  original 
request. 
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Street  *  ’  — 

Ci^,  State,  Zip  [ 

. .1 

1 . 

Leave  Phone  * 

Begin  Leave  *  j 

r 

End  Leave  | 

[ . : 

Nun.  .er  of  Lays  on  Leave  | 

r" 

Reason  for  Request  | 

. J 

My  e-mail  address  is:  * 
First  Approval 
Second  Approval 
Final  Approval 


jthehannahs^e  grid.net 


li 


I  J 

I  Executive  Officer  (XO)  ^ 


^Required  Fields 

When  this  form  is  submitted,  an  email  notification  of  your  leave  request  will  be  sent  along  die  approval  rhawi  of  command. 

Caii*t  filid  yonr  record?  Clide  Here  to  Add  N wv  persoiind  to  the  database. 


'  Qsesss^issdjim.  ■' 


Figure  7.2  -Online  Leave  Request  Form 


If  the  user  selected  the  Procurement  Request  form  on  the  main  page.  Figure  7.1, 
the  online  Procurement  Request  form  is  displayed  as  shown  in  Figure  7.3.  Utilizing  this 
form  a  member  can  order  a  part  online  and  maintain  tracking  until  the  part  is  delivered  to 
its  destination.  Once  the  required  data  is  filled  out  in  Figure  7.3,  the  user  mouse  clicks  on 
the  "submit"  bar  at  the  bottom  of  the  screen  to  enter  the  description  of  items  that  need  to 
be  ordered. 
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L-KateieC’^oxie  of PmbatffCdic^ 


..  OrtJm^  Fcn-.w: 


I*rartittg:  j  ESU  Alameda  ^ 

Z.3^^-rf%q^si.'’;;’  ••'  .V’V'.-':'  .•  "■^-  ''V- ■;'-" 

HewRequest  ^ 

4' iirfoonalioa 


Public  J'.cacs 


5.  Approving  GMScUils 


Approving  Officials 

(A) 


(1)  AuthcmzeciRcquisitionetHame 
Kune;  jCDREdLane 

Accounting  CftitjficeUon  Officer 
Name:  }  SKC  Darvin  Bennett  j 

(^St^eroisor 


6;  Coasig^  <ihd  D«stiatitio& 


COMMANDING  OFRCEa  ESU  ALAMEDA 


BLDG  Z1  RH128  COAST  GUARD  ISLAND 


Cil^  lALAMEDA 
State:  Zip:|90Q00 


Routing  Symbol 

(J3) 


(Storekeeper 


71  OeteRMpiired 

8;<3tivemm«at'  :: 
Rmniabed  ■  ■  ' 


‘  ThtbnCiAPmiUtaf  LX^ 
^Vogwan  EleowntCode) 

IW(»TAC  ttk  PR  Si9|i«i«s 

(dbsiCen&e^  . 


(ESU  Alam«da/MlJCP(T) 


b^-^, Start 


Figure  7.3  -  Online  Procurement  Request  Form 
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Figure  7.4  presents  the  online  form  for  requesting  supply  parts  that  need  to  be 
ordered.  If  more  than  five  items  need  to  be  ordered  at  one  time  additional  forms  may  be 
pulled  up  from  this  screen. 


Hrrne 

Mil 


■■irons  Lc’.v 


TaI' 


strati** 

r'Aic  A'MrCi 


Electronic  Support  Unit  Alameda  Intranet 


Part  2:  Pffl  out  fee  Description  of  Items  or  Sergices  you  wish  to  purchase. 


9^ .  Sern^  ■ 

!U«ixi  or  Sonice 


QTT 


C  jTP: 

B  rin-.-.';  rr-o: 


Intt  u.ft  K*-h' 


Figure  7,4  -  Online  Procurement  Request  Data  Description  Form 


As  previously  mentioned  the  left  frame  remains  consistent  throughout  each  form 
allowing  the  user  to  access  other  areas  of  the  Intranet  as  desired.  Figure  7.4  portrays  this 
logic. 

D.  DATABASE 

Although  the  tables  used  within  the  developed  databases  is  part  of  the  prototype 
intranet,  the  designed  forms,  quires  and  reports  are  not.  In  this  case,  these  forms,  queries. 


and  reports  were  used  to  test  the  proposed  business  process,  ensure  the  functional  use  of 
the  data  was  correct,  and  define  the  specifications  for  active  server  scripting  by  another 
thesis  team  working  conjointly  on  this  project.  In  addition,  the  database  itself  can  be 
used  to  retrieve  critical  supply  tracking  data  in  the  event  the  intranet  fails  to  operate, 
offering  a  redundant  system. 

This  section  will  illustrate  the  design  of  the  Procurement  Request  (PR)  form  with 
the  remaining  Supply  Tracking  System  forms  placed  in  Appendix  D.  The  screen  shots 
that  are  presented  are  from  forms  created  in  Microsoft's  Access  97. 

Since  the  database  tables  are  an  integral  part  of  the  intranet,  any  unauthorized 
modifications  to  these  tables  could  result  in  the  failure  of  the  intranet  itself  For  this 
reason,  advanced  features  are  used  within  Access  97  to  hide  the  tables  from  the  user. 
This  does  not  however  prevent  the  user  from  using  the  database  as  a  redundant  system. 
When  a  user  attempt  to  load  the  database  using  Access  97  the  first  thing  they  will  see  is 
the  opening  disclaimer  shown  in  Figure  7.5. 


1*::  Discldimet  F  ciiin 

ESl 

>  /  -  i  ?  i 

dte  Bers<mnaTmMii9  S^fstatiDc^ 

noneboo^^. 

Dang so^nU damage ihe 

r^SaMe€pemb<m^aaInin0tA 

.r:  /  .  To  i^^datedaia  within  eiAerdaiabase,  use 

\  *c '''3'^'33- v-v'-v'"" '  ■ 

v  „  ^  \  [  the  ike  premadeforms  opaUa^fiwnike  daktbase 

3  X3,r  -'L  -■  •' 

.  Figure  7.5  -  Database  Disclaimer 
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Once  the  disclaimer  has  been  read  the  user  clicks  on  the  Continue  button  to  access 


the  ESU  Alameda  Supply  Tracking  System.  Figure  7.6  offers  the  user  the  choice  of 
continuing  on  to  the  Forms  and  Status  Updates,  read  the  disclaimer  again,  or  exit  the 
database. 


Figure  7.6  -  Database  Main  Menu 


Entering  the  Forms  and  Status  Updates  area  the  user  is  again  provided  with  the 
four  menu  options.  Figure  7.7  reveals  the  user’s  options. 

The  detail  built  into  each  of  the  following  forms  offers  the  ability  to  automatically 
receive  tracking  updates,  search  archived  information,  obtain  status  updates,  and 
decentralize  tracking  responsibility  to  the  lowest  level.  Embedding  this  functionality  into 
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the  look  and  feel  of  existing  paper  forms  reduces  the  amount  of  training  required  and 
enhances  the  acceptance  of  the  intranet  as  a  business  tool. 


Figure  7.7  -  Forms  and  Status  Update  Menu 


Figure  7.8  shows  the  Procurement  Request  (PR)  form.  The  PR  number  in  the 
upper  right  hand  comer  of  the  form  uniquely  identifies  each  form.  The  parts  ordered  on 
each  form  could  be  tracked  and/or  changed  based  in  this  number. 

Extensive  use  of  drop-down  boxes  enabled  the  use  of  a  knowledge  base  where 
users  selected  known  information  to  input  specialized  supply  codes  which  historically 
required  extensive  Storekeeper  time  to  look  up.  In  addition,  the  use  of  default  values 
decreased  the  amount  of  time  required  to  fill  in  recurring  or  look  up  unknown 
information.  As  shown  in  Figure  7.8,  block  6  is  a  defaulted  value.  This  default 
Command  information  will  always  be  the  same  for  Purchase  Orders  (PR's)  originating 
fi-om  ESU  Alameda.  Many  other  blocks  such  as  blocks  1,  2,  and  5  contain  drop-down 
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Several  Uems  may  be  included 
'  here,  be  sure  and  scroll  through  the 

iJfdef  Subtotaf:  }  00 


.■  P^.IST  •  ,  r  2ND  r  3RD  P  4TH 


Fundmg/Visa 

ISKUieOnivl 


^  Partial  r  pu  r  NolYel  Recw»e3 


^  •  A?-AliC?rw*a«  ,  .  CasJCwa 

.  ■  ■:Ca/33  ■ZaJtn  ■  CjisrjrtY 

"Tj  Vf  stn il33 j3(V0/5P  :zJf0180> 


|CW03  Steven  Ward 


•  Tjos  yv  •  ■.. 

"j  21  |98j:j|l234AAA 


'  :  .Prp^. 

T~qT 


ill  '  -li  '  -il  '  I  Update 

New  j  Delete  I  •  Status  Log 

Figure  7.8  -  Database  Procurement  Request  Form 


108 


E.  DATABASE  UPDATE  AND  MAINTENANCE  OF  FORMS 


Information  provided  within  the  database’s  drop-down  boxes  is  dynamically 
changing  as  a  result  of  such  things  as  military  transfers  and  changes  in  duty  assignments. 
For  these  reasons,  the  design  team  added  update  functionality  to  the  database  to  enable 
the  user  to  quickly  and  easily  update  these  forms  with  current  information.  Since  each 
field  in  each  form  is  associated  with  an  update  form,  the  user  always  has  the  ability  to 
update  missing  or  incorrect  information  quickly.  To  update  the  data  in  any  drop-down 
box,  all  the  user  has  to  do  is  double-click  the  incorrect  field  with  the  left  mouse  button  to 
bring  up  the  needed  form.  Figure  7.9  shows  such  a  form,  in  this  case  the  unit  of  issue  for 
parts  would  be  used  to  add  the  ‘BG”  symbol  for  bag. 


Figure  7.9  -  Unit  Of  Issue  Lookup  Table  Update  Form 
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If  a  field  already  contains  information  in  it,  such  as  a  default  address,  and  a  need 
exists  to  input  different  data,  the  user  can  enter  the  required  data  directly  into  the 
corresponding  area.  If  the  user  attempts  to  call  an  update  form  by  double  clicking  in  the 
field  utilizing  the  default  value,  the  user  will  be  told  to  input  the  data  directly  as  shown  in 
Figure  7.10. 


Figure  7.10  -  Default  Data  Feedback 


F.  STATUS  LOG 

As  previously  mentioned,  tracking  the  status  of  each  part  and  providing  updates  to 
various  crewmembers  required  over  25%  of  the  Storekeepers  time.  It  is  primarily 
because  the  SK  was  the  only  person  tracking  the  parts  and  continually  repeating  updates 
up  and  down  the  chain  of  command.  Under  the  new  business  model,  the  responsibility  to 
update  parts  falls  to  the  division  ordering  the  part.  As  updates  are  performed,  they  are 
now  tracked  through  the  use  of  a  Status  Log,  a  system  that  did  not  exist  under  the  old 
business  model.  Figure  7.11  shows  the  Bill  Of  Lading  Status  Check  form.  This  fi’om  is 
typical  and  used  in  the  same  way  for  the  various  types  of  supply  forms.  Each  time  a  user 
obtains  new  information  on  a  supply  item,  they  will  share  this  information  with  everyone 
in  the  command  by  logging  it  onto  this  form.  By  using  this  methodology.  The  database 
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will  maintain  current  information  as  to  when  the  part  was  originally  ordered,  shipped,  and 
any  incidental  information  received  on  the  part  before  it  arrives.  Anyone  seeking 
information  on  this  part  can  access  the  log  and  review  the  part  history  without  requiring 
the  assistance  of  another  person,  which  has  historically  been  the  Storekeeper.  The  log  is 
closed  out  upon  arrival  of  the  part  by  placing  a  check  mark  in  the  received  box  on  the 
form.  To  maintain  accuracy  and  accountability  of  all  input  data,  the  user's  name  is 
entered  each  time  a  status  update  is  accomplished. 


Si  BOL  _Stalus_Log_lnput_Form  :  Form 


YouVe  entexed  Bill  Of  Ladini;  Status  Il^date  Ibzm.  If  you  have 
infiixmatioiL  to  add  to  the  list,  or  if  you  need  to  modii^  the  status 
los^  this  is  the  iplace  to  do  it  This  in&imation  will  he  used  to 
archive  status  in&xmation  and  identii^  those  items  xequixins 
.  i^dates  (so  he  sure  you  put  in  the  date!]lL 


Dale  of  Thii 


Hew  Stafui  of  Part 


Tod^^Dateis:4/t3^ 

Haine  of  Pefsoit  . 
P^fofinirta  Thls  D^pd^e 


this  is  a  test 


“3;^v 


at  p^arii^v 


JlJ 

j  ’  Saw  I 


:  1  / 


V  The  entire  history  of  this  item  may 
:  ^  be  included  here,  be  sure  and 

;  - ^  through  the  list  to  see  them 

.  ■  1  .  .  all.  Select  ‘New  Update'  to  add  to 

:  Ddete  .  |  ,  ihe  list. 

- - - - - - - - 


ill 


iii'ii'- 


Figure  7.11  -  Bill  Of  Lading  Status  Log  Update  Form 
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G.  CONCLUSION 


This  chapter  explained  the  importance  of  the  graphical  user  interface  and 
presented  various  screenshots  of  the  ESU  Alameda  intranet  design  specification.  It 
explained  how  the  use  of  database  designs  enabled  a  development  that  met  the  business 
models  established  in  chapter  six  and  offered  several  screen  shots  to  assist  the  reader  in 
understanding  the  uses  of  this  rapid  prototype  development  effort.  Although  not  all 
forms  were  incorporated  onto  the  Intranet,  the  data  modeling  research  was  performed  and 
is  included  in  Appendix  D  for  use  in  future  development  efforts. 
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vm.  CONCLUSION 


A.  INTRODUCTION 

The  amounts  of  business  and  technical  research  required  for  intranet  development 
is  extensive,  and  despite  the  vast  amounts  of  data  analysis  accomplished  within  this  thesis, 
there  are  many  more  facets  which  must  be  considered  before  an  effective  intranet  can  be 
employed  at  a  government  installation.  Since  the  design  and  implementation  phases  of  this 
project  vdll  be  accomplished  by  a  different  thesis  student  jointly  working  on  this  project, 
discussions  of  such  material  will  be  left  for  presentation  within  that  thesis.  Nonetheless,  a 
brief  discussion  of  business  policy,  need  for  organizational  learning,  security,  and  lessons 
learned  will  be  provided  as  the  conclusion  to  this  thesis. 

B.  BUSINESS  POLICY 

The  effects  of  government  downsizing,  restructuring,  and  streamlining  have  placed 
many  new  challenges  on  ESU  Alameda,  with  one  of  the  largest  being  the  management  of 
available  time.  Although  much  thought  has  been  put  into  the  conceptual  design  of  this 
prototype  intranet,  it  does  not  guarantee  successful  results  without  the  creation  of  a  well 
established  policy  for  intranet  use.  While  creativity  must  be  encouraged,  the  organization 
must  not  allow  a  paradox  to  exist  where  the  publishing  of  artistic  work  becomes  more 
important  than  the  information  itself  In  other  words,  the  policy  must  continually  weigh 
the  benefits  of  the  intranet  against  the  costs  of  its  use  and  make  policy  adjustments  for  any 
area  which  fails  to  meet  the  original  intent  of  application. 
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C.  ORGANIZATIONALLEARNING 


The  ESU  command  must  recognize  that  the  use  of  an  intranet  will  create  a 
technologicaUy  driven  paradigm  shift  within  the  organization.  Since  this  will  be  a  new 
experience  for  the  majority  of  the  organization,  it  will  therefore  require  some  amount  of 
organizational  learning  to  be  successful.  Although  some  members  will  find  the  concept  of 
intranet  collaboration  easy,  others  will  have  a  difficult  time  adopting  to  this  new  way  of 
business  for  various  reasons.  One  reason  this  difficulty  exists  is  found  in  the  impeding 
mental  models  of  the  individual  users.  Depending  on  the  extent  of  these  mental  models, 
individual  users  could  unintentionally  restrict  system  functionality  and  defeat  the  intrinsic 
purposes  of  the  intranet.  One  reason  this  is  true  is  because  the  mental  model  is  tacit  and 
exists  below  any  level  of  user  or  command  awareness.  Therefore,  it  is  highly 
recommended  the  command  meet  with  small  groups  of  users  before  implementing  the 
intranet  to  examine  the  mental  models  of  the  organization  and  sell  the  concept  of  intranet 
use.  Once  the  organization  recognizes  and  challenges  their  own  mental  models,  true 
organizational  learning  can  begin.  So  simply  put,  even  if  a  user  is  forced  to  comply  with 
intranet  use,  the  full  advantages  of  the  intranet  will  not  be  recognized  until  each  user 
challenges  their  own  mental  models  and  enables  uninhibited  organizational  learning. 
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D.  SECUKITY 


Several  diflFerent  types  of  hardware  and  software  security  products  exists  to  meet 
the  operational  requirements  of  ESU  Alameda,  many  of  which  the  organization  may 
already  be  aware  of  in  using  the  Microsoft  Windows  NT  networking  platform.  Although 
it  is  not  the  intent  of  this  thesis  to  forecast  the  future  security  requirements  of  ESU 
Alameda,  or  to  choose  the  optimum  mix  of  hardware  and  software  products  on  the  market 
to  meet  these  requirements,  we  would  like  to  introduce  the  reader  to  the  types  of  common 
security  measures  available  and  briefly  describe  how  ESU  Alameda  may  use  them  if  so 
desired.  The  common  security  measures  include; 

♦  Authentication  ♦  Firewalls 

♦  Access  Control  ♦  System  Integrity 

♦  Cryptography  ♦  Auditing 

1.  Authentication 

The  function  of  the  authentication  process  is  to  identify  the  user  to  the  computer 
system  by  means  of  a  password.  For  the  computer  system,  this  ensures  the  user  is  who 
they  claim  to  be  so  proper  access  to  restricted  files  can  be  managed.  For  the  user,  this 
prevents  the  need  to  sign  into  multiple  systems  local  and  remote  systems,  since  the 
authentication  process  is  only  required  once  for  each  session.  During  the  design  of  the 
intranet,  at  least  four  stages  of  generic  authentication  should  be  implemented  for  the 
following  reasons; 
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a.  Administrative,  for  overall  administration  of  the  intranet 

b.  Command,  for  signature  control  of  the  CO  and  XO 

c.  Supervisor,  for  signature  control  of  division  supervisors 

d.  User,  for  signature  control  of  individual  users. 

Additional  control  could  be  implemented  if  each  user  was  provided  individual  access 
privileges,  however,  this  would  create  additional  administrative  maintenance  issues  which 
may  not  be  warranted  for  ESU  Alameda. 

2.  Access  Control 

The  primary  role  of  access  control  within  each  intranet  application  will  be  to 
enable  signature  authority  and  possibly  viewing  privileges  based  on  the  command  position 
held  within  the  organization.  Since  there  ejdsts  little  need  to  establish  and  manage  a 
system  for  individual  access  control,  a  generic  system  could  be  used  to  minimize  the 
administrative  burden  of  the  command.  This  is  possible  because  there  exists  a  since  of 
trust  within  the  ESU  organization.  For  this  reason,  the  combined  use  of  authentication 
and  access  control  will  prevent  the  accidental  authorization  of  intranet  request  by  junior 
command  members  for  such  things  as  leave  requests  and  supply  budget  authorization 
forms.  It  is  this  feature  that  will  compare  a  users  logged  in  authorization  against  the 
access  control  level  associated  with  the  various  form  sections  within  the  intranet. 

3.  Cryptography 

Cryptography  is  primarily  used  when  sending  sensitive  data  across  an  unsecured 
network.  There  are  various  types  employed,  vdth  each  offering  a  mechanism  to  scramble 
the  data  in  a  way  that  only  the  intended  user  can  unscramble  and  read  it.  Since  ESU 
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Alameda  is  not  operating  in  a  highly  secure  environment,  the  need  for  the  additional 
functionality  of  cryptography  above  that  already  provided  by  commercially  available  free 
web  browsers  is  not  required. 

4.  Firewalls 

The  primary  purpose  of  firewalls  is  to  protect  the  safety  of  a  site  against  malicious 
attack  from  personnel  outside  the  organization.  Since  ESU  Alameda  should  use  an 
extranet  to  share  information  v^th  customers,  as  well  as  allow  internet  access  for 
employee  research,  the  use  of  a  firewall  is  highly  suggested.  Since  there  are  numerous 
different  types  of  firewalls,  as  well  as  pricing  and  maintenance  considerations  to  consider, 
we  suggest  ESU  Alameda  hire  a  professional  firewall  provider  to  ensure  the  firewall  is 
properly  selected,  initialized,  tested,  and  maintained. 

5.  System  Integrity 

The  need  for  integrity  protection  is  similar  to  the  need  for  cryptography.  Any  time 
data  is  sent  across  an  unsecured  network,  there  exist  the  possibility  someone  can  read  the 
data  if  it  is  not  encrypted.  A  potentially  worse  case  scenario  would  be  if  the  data  were 
altered  and  then  sent  to  the  intended  person.  By  using  one  of  the  many  types  of  integrity 
methods,  each  member  possesses  assurance  that  the  data  came  unaltered  from  the  person 
claimed.  For  similar  reasons  as  cryptography,  this  functionality  is  already  adequately 
provided  for  ESU  Alameda  vsithin  the  web  browsers  and  is  not  considered  an  additional 
requirement  for  intranet  development. 
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6.  Auditing 

By  enabling  auditing  an  organization  can  log  all  attempts  made  to  access  the 
intranet  or  extranet  system.  In  addition  to  tracking  the  number  of  unauthorized  access 
attempts  made  to  the  system  for  security  monitoring,  the  command  could  also  measure  the 
access  to  published  data  to  see  if  the  data  published  was  worth  the  efforts  to  make  it. 
Because  ESU  Alameda  will  be  using  Microsoft  Windows  NT  Server,  they  already  possess 
the  ability  to  turn  this  feature  on  and  off,  and  therefore  do  not  require  further  development 
as  part  of  the  intranet  design.  Since  the  use  of  this  feature  has  a  negative  impact  on 
systems  performance,  it  should  only  be  enabled  when  a  need  exists,  and  then  disabled  at 
again  at  the  first  opportunity. 

E.  LESSONS  LEARNED 

This  section  provides  the  reader  with  some  of  the  lessons  learned  while  designing 
this  project.  It  is  primarily  intended  to  assist  future  designers  of  such  an  application. 

1.  Need  For  Positive  Designer  And  Customer  Relations 

We  were  extremely  fortunate  to  find  a  customer  who  was  extrinsically  and 
intrinsically  motivated  to  discuss  new  business  opportunities.  Because  of  the  complexities 
and  difficulties  experienced  with  data  analysis,  this  project  would  not  have  succeeded  if 
not  for  the  ongoing  feedback  the  ESU  crew  provided.  It  is  strongly  recommended  that 
only  customers  with  this  commitment  be  considered  for  business  analysis  considerations. 
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2.  Need  To  Understand  The  Scope  Of  The  Project 

A  project  of  this  sort  is  a  huge  undertaking  capable  of  quickly  developing  into  a 
task  much  larger  than  anticipated  or  desired  for  the  limited  development  time  available. 
When  starting  such  a  project,  recognize  the  following: 

♦  Team  members  will  differ  in  opinion,  requiring  additional  research  and  rework 
of  completed  tasks.  Although  this  is  good  for  the  design  of  the  finished 
product,  it  took  more  time  than  anticipated  and  was  a  major  factor  in  delays 

♦  Product  design  goals  will  change  much  more  than  anticipated.  Changes  come 
fi-om  the  unit  as  well  as  other  team  members.  This  has  similar  effects  as  the 
previous  bullet  and  is  another  cause  for  unplanned  delays. 

♦  Team  members  become  tunnel  visioned.  By  definition  of  the  rapid  prototype 
development,  the  system  is  not  designed  to  work.  However,  in  retrospect  we 
found  we  spent  days  fixing  designs  which  previously  worked,  or  which  we 
couldn't  get  to  work  suitable  for  a  finished  product.  More  emphasis  needs  to 
be  placed  on  rapid  prototyping  instead  to  prevent  it  fi-om  turning  into  the  build 
and  fix  methodology. 

3.  Need  For  Skills  Development 

With  more  than  2000  pages  of  text  read  in  preparation  for  this  project,  much  more 
time  was  required  to  gain  the  needed  skills  than  was  anticipated.  We  suggest  you 
quadruple  the  time  allotted  for  this  task. 
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4.  Software  Bugs  Or  Restrictions  Of  Use 

Attempting  to  resolve  software  bugs  and  limitations  of  student  edition  CASE  tools 
provided  this  team  the  largest  amount  of  frustration  for  the  entire  project.  Before  starting 
such  a  project,  preview  applicable  newsgroups  and  web  sites  to  gain  an  understanding  of 
the  software  constraints  you  will  come  across  before  you  spend  days  trying  to  solve  a 
problem  that  you  can  not  fix. 

5.  Need  For  Patience  And  Pacing 

In  attempts  to  make  up  the  lost  time  associated  vdth  software  bugs,  longer  learning 
curves  than  anticipated,  delays  associated  with  reengineering  efforts,  and  the  teams 
intrinsic  desire  to  resolve  all  encountered  problems,  team  members  began  to  get  restless 
and  began  working  abnormal  hours  in  attempts  to  catch  up.  Fatigue  made  matters  worse 
and  eventually  the  perceived  scope  of  the  project  was  scaled  back  to  an  obtainable  level, 
more  in  lines  with  the  original  projections.  It  is  highly  recommended  that  future  teams 
taking  on  this  type  of  project  accept  these  delays  and  learn  to  use  them  as  positive  learning 
experiences  instead  of  failures  to  meet  obligations.  We  feel  adjusting  to  these  finstrations 
and  enhancing  team  management  skills  to  be  one  of  the  biggest  lessons  learned  in  this 
project. 
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F.  CONCLUSION 


Although  the  thesis  analyzed  the  existing  business  models,  data  flows,  and 
technical  aspects  required  for  intranet  development,  additional  work  will  still  be  required 
by  ESU  Alameda  to  enable  the  organization  to  learn  and  accept  the  new  policies  and 
operating  procedures.  As  a  conclusion  to  this  thesis,  the  reader  was  provided  several 
types  of  security  systems  available  for  consideration  as  well  as  a  list  of  our  lessons  learned 
to  aide  in  future  design  capabilities. 
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APPENDIX  A.  TRIP  REPORT 


Subject:  Initial  visit  to  ESU  Alameda,  Alameda  California,  4-7  December  1998 


Team  Members:  LT  Benhart 

LT  Dardis 
LT  Hannah 


NPS  Student  (USCG) 
NPS  Student  (USCG) 
NPS  Student  (USCG) 


Purpose:  Familiarization  with  ESU  Alameda’s  functions,  processes,  challenges,  goals, 
and  requests  for  the  development  of  a  prototype  Intranet  specification. 


People  Contacted:  Dean  Waring 

CDR  Lane 
LCDR  Hernandez 
LT  Nelson 
LTJG  Raush 
CW04  Weldon 
CW03  Ward 
CW02  Olsen 
TCCS  Clarke 
SKC  Bennett 
ETC  Bartlett 
GS12  Gainer 
GS12  Usher 
GSll  Spiva 
GS9  Wallace 


ESU  Coordinator  (ESU’s  Boss) 

CO 

XO 

Computer  Branch  Chief 
Electronics  Branch  Chief 
Shore  Section  Supervisor 
Telecommunications  Section  Supervisor 
Vessels  Section  Supervisor 
Frequency  Manager 
Storekeeper 

Alternate  Contracting  Representative 
Computer  Support  Section  Supervisor 
Networks  Section  Supervisor 
Contracting  Representative 
Telecommunications  Manager 


Upon  arrival,  LT  Benhart,  LT  Dardis  of  the  specification  development  team  and 
LT  Hannah  of  the  applications  development  team  conducted  an  initial  briefing  with  the 
Commanding  and  Executive  Officer.  Points  of  topic  included  establishing  the  objectives 
of  the  project,  limiting  expectations  of  the  unit,  and  providing  background  information  on 
team  members.  The  command  provided  the  team  with  unit  familiarization,  command  and 
control  oversight,  existing  command  challenges,  current  state  of  fluctuation  relative  to  a 
streamlining  initiative,  political  profile,  existing  stakeholders,  and  hardware/software 
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design  constraints.  Schedules  were  established  for  a  more  detailed  interviews  later  in  the 
day. 

Due  to  limited  available  time  the  initial  plan  of  the  team  was  to  collect  specific 
requirements  by  interviewing  top  management,  and  to  gather  existing  forms,  applications, 
and  written  procedures  to  study  data.  Existing  procedures  and  divisional  challenges  were 
to  be  determined  by  conducting  group  interviews  with  key  workers  and  middle  managers, 
then  using  questionnaires  to  collect  specific  process  information  from  these  members. 
Constraints;  ESU  Alameda  recently  received  new  Pentium  based  computers  which  will 
be  upgraded  to  a  Microsoft  Windows  NT  4.0  and  OflBce  97  networked  platform.  Since 
this  hardware  and  software  will  be  the  supported  standard  for  Coast  Guard  Units,  it  will 
be  used  for  project  development. 

Lessons  Learned;  More  time  was  required  than  anticipated  to  gather  the  required 
information.  The  use  of  questionnaires  was  a  fiuitless  effort  offering  no  benefit  to  this 
project.  This  is  primarily  because  the  employees  did  not  fully  understand  what  information 
the  team  wanted,  felt  they  could  not  adequately  transcribe  their  changing  roles,  and  felt 
their  processes  were  uniquely  event  driven  each  day.  To  work  around  this  challenge,  the 
team  conducted  a  quick  training  session  on  the  use  of  data  flow  diagrams  (DFDs)  and 
iteratively  used  this  tool  in  a  group  environment  to  transcribe  daily  routines  on  large 
drawing  boards.  With  the  team  acting  as  facilitators  and  transcribing  the  needed  data 
during  group  conversations,  detailed  process  evaluations  were  enabled. 
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To  assess  project  risk,  a  testing  of  the  political  environment  was  performed  by 
discussing  the  concept  of  a  prototype  Intranet  with  all  levels  of  the  organization,  as  well  as 
critical  stakeholders  external  to  the  organization.  No  political  problems  were  identified. 
Conclusion:  ESU  Alameda  is  an  innovative  organization  that  could  benefit  from  Intranet 
technology.  The  command  is  extremely  willing  to  use  new  technologies,  modify  business 
processes,  and  take  risks  in  attempts  to  enhance  customer  service.  In  addition,  they  are 
both  intrinsically  and  extrinsically  motivated  to  tackle  the  learning  challenges  of  Intranet 
use. 

The  teams  obtained  extensive  information  that  must  now  be  analyzed  and  refined. 
Open  communications  were  established  between  team  members  and  critical  employees  of 
the  command  for  prototype  feedback  and  data  refinement. 

The  team  would  like  to  thank  the  crew  of  ESU  Alameda  for  taking  the  time  to 
assist  them  with  this  project.  We  hope  we  can  all  benefit  from  this  experience. 


125 


126 


APPENDIX  B  DATA  FLOW  DIAGRAMS 


Context  Level  Diagram  B.l-  COTR  Modifications 
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Request 


Level  0  Data  Flow  Diagram  B.2  -  COTR 
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Context  Level  Diagram  B.3  -  Shore  Section  Chief  CASREP 
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Level  0  Data  Flow  Diagram  B,4  -  Shore  Section  Chief  CASREP 
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Context  Level  Diagram  B.5  -  COTR  CASREP 
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Level  0  Data  Flow  Diagram  B.6  -  COTR  CASREP 
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APPENDIX  C  PROCESS  DESCRIPTIONS 


LEAVE  REQUEST 


Context  Level  Diagram  Description  (Figure  6.6):  The  Leave  Request  process 
enables  a  person  to  request  leave,  and  gain  approval  from  immediate  supervisors  and 
finally  the  Executive  Officer  for  final  approval  to  take  requested  leave. 

Process  1.0  Description  (Figure  6.7):  This  process  documents  the  request  for 

leave. 

1.  What  entities  does  this  process  effect?  People  requesting  leave. 

2.  How  many  users  does  this  process  have?  One. 

3.  Who  is  the  primary  owner  of  this  process?  Person  requesting  leave. 

4.  How  often  is  this  process  used?  On  average,  someone  executes  this  process 
within  the  command  several  times  each  month. 

5.  How  often  is  this  process  updated?  Same  as  No.4. 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  This 
process  uses  multiple  updates  and  multiple  queries.  Most  requests  come  in 
the  form  of  email. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information 
is  unclassified  but  sensitive. 

8.  What  is  the  source  of  information  for  this  process?  The  person  requesting 
leave  initiates  the  process. 
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9.  What  is  the  current  status  of  the  process?  This  process  is  currently  not  on 
the  ESU  Intranet  and  is  manually  accomplished  by  sending  email  to  and  from 
the  supervisor,  the  supervisor's  supervisor,  and  the  Executive  Officer  until  the 
request  is  either  approved  or  denied. 
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LEAVE  REQUEST 


Process  2.0  Description  (Figure  6.7);  This  process  transfers  the  request  from 
person  to  person  with  the  email  files  acting  as  the  archive  for  leave  taken. 

Process  2.1  Description  (Figure  6.8):  This  determines  the  days  of  leave  to 
request  and  fills  out  the  leave  form. 

1.  What  entities  does  this  process  effect?  People  requesting  leave. 

2.  How  many  users  does  this  process  have?  Everyone  at  the  command. 

3.  Who  is  the  primary  owner  of  this  process?  People  requesting  leave. 

4.  How  often  is  this  process  used?  On  average,  someone  executes  this  process 
within  the  command  several  times  each  month. 

5.  How  often  is  this  process  updated?  Same  as  No.4. 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  This 
process  uses  multiple  updates  and  multiple  queries. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information 
is  unclassified  but  sensitive. 

8.  What  is  the  source  of  information  for  this  process?  The  person  requesting 
leave  initiates  the  process. 

9.  What  is  the  current  status  of  the  process?  This  process  is  currently  not  on 
the  ESU  Intranet  and  is  manually/mentally. 


135 


LEAVE  REQUEST 


Process  2.2  Description  (Figure  6.8):  This  process  initiates  the  email  for  leave 
request  for  the  person  requesting  leave,  immediate  supervisor,  additional  supervisor,  and 
finally  the  Executive  Officer  for  final  approval  or  denial. 

1.  What  entities  does  this  process  effect?  The  people  requesting  leave, 
supervisors,  and  Executive  Officer. 

2.  How  many  users  does  this  process  have?  Everyone  at  the  command. 

3.  Who  is  the  primary  owner  of  this  process?  The  people  submitting  the  leave. 

4.  How  often  is  this  process  used?  On  average,  someone  executes  this  process 
within  the  command  several  times  each  month. 

5.  How  often  is  this  process  updated?  Same  as  No. 4. 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  This 
process  uses  multiple  updates  and  multiple  queries. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information  is 
unclassified  but  sensitive.  The  volume  of  information  will  be  changed  from  day 
to  day. 

8.  What  is  the  source  of  information  for  this  process?  The  person  requesting 
leave  initiates  the  process,  everyone  else  reviews,  comments,  and  forwards  the 
request. 

9.  What  is  the  current  status  of  the  process?  This  process  is  currently  not  on  the 
ESU  Intranet  and  is  manually  accomplished.  Email  is  used. 


136 


LEAVE  REQUEST 


Process  2.3  Description  (Figure  6.8);  This  process  monitors  the  leave  request  in 
a  waiting  pattern  for  an  answer. 

1.  What  entities  does  this  process  effect?  The  people  requesting  leave, 
supervisors,  and  Executive  Officer. 

2.  How  many  users  does  this  process  have?  Everyone  at  the  command. 

3  Who  is  the  primary  owner  of  this  process?  People  requesting  leave. 

4.  How  often  is  this  process  used?  On  average,  someone  executes  this  process 
within  the  command  several  times  each  month. 

5.  How  often  is  this  process  updated?  Same  as  No.4. 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  This 
process  uses  multiple  updates  and  multiple  queries. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information  is 
unclassified  but  sensitive.  The  volume  of  information  will  be  changed  from  day 
to  day. 

8.  What  is  the  source  of  information  for  this  process?  The  person  requesting 
leave  waits  for  supervisor's  input  as  well  as  final  approval.  Feedback  in  needed 
for  the  requesting  person  to  know  that  the  supervisor  has  forwarded  the  request 
without  taking  personnel  time.  The  same  process  holds  true  once  the 
supervisor(s)  forward  the  request  and  wait  for  the  decisions  from  the  above  chain 
of  command. 
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9.  What  IS  the  current  status  of  the  process?  This  process  is  currently  not  on  the 
ESU  Intranet  and  is  mentally  accomplished  by  the  initiator  and  all  supervisors. 
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PARTS  ORDERING 


Context  Level  Diagram  Description  (Figure  6.9):  The  fimction  of  the  Parts 
Ordering  process  is  to  act  as  focal  point  for  all  of  the  command  parts  request,  including 
budget  verification,  quality  control,  ordering,  tracking,  forecasting,  and  transportation  of 
materials.  This  process  is  the  cornerstone  to  making  the  command  operate  efficiently  and 
is  the  number  one  request  of  the  command  to  attempt  to  resolve. 

1.  Process  1.0  Description  (Figure  6.10):  This  process  verifies  all  requests  are  in 
the  proper  format  and  are  requesting  proper  quantities. 

2.  What  entities  does  this  process  effect?  ESU  branch  personnel. 

3.  How  many  users  does  this  process  have?  All  ESU  employees  (90-100). 

4.  Who  is  the  primary  owner  of  this  process?  The  unit  Storekeeper  (SK). 

5.  How  often  is  this  process  used?  This  process  is  executed  several  times  per  day. 

6.  How  often  is  this  process  updated?  Same  as  No.4. 

7.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  This 
process  uses  multiple  updates  and  multiple  queries.  Most  requests  come  in  the 
form  of  email,  message  traffic,  and  forms. 

8.  What  type  of  information  does  this  process  use?  Most  of  this  information  is 
unclassified  but  sensitive.  The  volume  of  traffic  vrill  change  from  day  to  day. 

9.  What  is  the  source  of  information  for  this  process?  The  technician  reports 
parts  requirements  and  priorities. 
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10.  What  is  the  current  status  of  the  process?  This  process  is  currently  not  on  the 
ESU  Intranet  and  is  manually  accomplished.  Updates  are  done  in  numerous  ways 
including  written  logs  and  word  processing,  spreadsheets,  and  forms.  All  of  this 
information  is  available,  but  will  be  difficult  to  pinpoint  A\dthout  a  prototype 
design  for  Intranet  use. 

11.  Time  Used;  Currently  the  unit  SK  spends  25%  of  his  time  informing  command 
personnel  on  the  status  of  parts  orders. 
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PARTS  ORDERING 


Process  2.0  Description  (Figure  6.10);  This  ensures  adequate  fiinds  are  available 
before  parts  are  purchased,  manually  files  paperwork  to  track  finding,  manually  logs 
ordering  details,  and  manually  enters  parts  request  in  a  proprietary  parts  ordering 
computer  network  system. 

1.  What  entities  does  this  process  effect?  ESU  Executive  Officer  (XO)  and 
ESU  employees. 

2.  How  many  users  does  this  process  have?  The  SK  is  the  sole  performer  of 
this  task,  but  it  is  done  for  every  member  of  the  command. 

3.  Who  is  the  primary  owner  of  this  process?  The  unit  SK. 

4.  How  often  is  this  process  used?  This  process  is  executed  several  times  per 
day. 

5.  How  often  is  this  process  updated?  Same  as  No.4. 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  This 
process  uses  multiple  updates  and  multiple  queries. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information 
is  unclassified  but  sensitive.  The  volume  of  traffic  will  change  from  day  to 
day. 

8.  What  is  the  source  of  information  for  this  process?  The  ESU  branches  will 
request  the  parts,  the  XO  will  authorize  the  funding,  and  the  SK  will  provide 
all  other  input. 
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9.  What  is  the  current  status  of  the  process?  This  process  is  currently  not  on 
the  ESU  Intranet  and  is  manually  accomplished. 
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PARTS  ORDERING 


Process  3.0  Description  (Figure  6.10);  This  process  determines  the  proper  type 
of  procurement  for  the  requested  part  (Ehirchase  Request,  GBL,  VISA,  or  MILSTRIP), 
and  logs  details  into  a  log  network  system. 

1.  What  entities  does  this  process  effect?  Transport  Office,  Finance  Office 

(F). 

2.  How  many  users  does  this  process  have?  The  SK  is  the  sole  performer  of 
this  task,  but  it  is  done  for  every  member  of  the  command. 

3.  Who  is  the  primary  owner  of  this  process?  The  unit  SK. 

4.  How  often  is  this  process  used?  This  process  is  executed  several  times  per 
day. 

5.  How  often  is  this  process  updated?  Same  as  No. 4. 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  This 
process  uses  multiple  updates  and  multiple  queries. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information 
is  unclassified  but  sensitive.  The  volume  of  traffic  will  change  fi'om  day  to 
day. 

8.  What  is  the  source  of  information  for  this  process?  A  variety  of  United 
States  Coast  Guard  regulations  govern  the  proper  ordering  procedures. 

9.  What  is  the  current  status  of  the  process?  This  process  is  currently  not  on 
the  ESU  Intranet  and  is  manually  accomplished. 
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PARTS  ORDERING 


Process  4.0  Description  (Figure  6.10);  This  process  determines  which  supplier 
the  part(s)  should  be  ordered  from  depending  on  the  source  of  funding  (VISA  or 
MILSTRIP). 

1.  What  entities  does  this  process  effect?  Supplier. 

2.  How  many  users  does  this  process  have?  The  SK  is  the  sole  performer  of 
these  tasks,  but  it  is  done  for  every  member  of  the  command  and  for  every 
part  ordered. 

3.  Who  is  the  primary  owner  of  this  process?  The  unit  SK. 

4.  How  often  is  this  process  used?  This  process  is  executed  several  times  per 
day. 

5.  How  often  is  this  process  updated?  Same  as  No.4. 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  This 
process  uses  multiple  updates  and  multiple  queries. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information 
is  unclassified  but  sensitive.  The  volume  of  traffic  will  change  from  day  to 
day. 

8.  What  is  the  source  of  information  for  this  process?  A  variety  of  United 
States  Coast  Guard  regulations  govern  the  proper  ordering  procedures. 

9.  What  is  the  current  status  of  the  process?  This  process  is  currently  not  on 
the  ESU  Intranet  and  is  manually  accomplished. 
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PARTS  ORDERING 


Process  5.0  Description  (Figure  6.10);  This  process  performs  a  quality  control 
check  of  received  orders  to  ensure  the  proper  type  of  part,  quantity,  and  physical 
condition  before  transport  to  the  requested  location. 

1.  What  entities  does  this  process  effect?  Transport  Office,  ESU  employees. 

2.  How  many  users  does  this  process  have?  The  SK  is  the  sole  performer  of 
these  tasks,  but  it  is  done  for  every  member  of  the  command. 

3.  Who  is  the  primary  owner  of  this  process?  The  unit  SK. 

4.  How  often  is  this  process  used?  This  process  is  executed  several  times  per 
day. 

5.  How  often  is  this  process  updated?  Same  as  No.4. 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  H?  This 
process  uses  multiple  updates  and  multiple  queries. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information 
is  unclassified  but  sensitive.  The  volume  of  traffic  will  change  fi’om  day  to 
day. 

8.  What  is  the  source  of  information  for  this  process?  A  paper  log  and 
physical  inspection. 

9.  What  is  the  current  status  of  the  process?  This  process  is  currently  not  on 
the  ESU  Intranet  and  is  manually  accomplished. 
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PARTS  ORDERING 


Process  6.0  Description  (Figure  6.10):  This  process  manually  fills  out  the 
MDLSTRIP  paperwork. 

1.  What  entities  does  this  process  effect?  None  directly. 

2.  How  many  users  does  this  process  have?  The  SK  is  the  sole  performer  of 
this  task,  but  it  is  done  for  every  member  of  the  command  each  time  a 
MELSTRIP  part  is  requested. 

3.  Who  is  the  primary  owner  of  this  process?  The  unit  SK. 

4.  How  often  is  this  process  used?  This  process  is  executed  several  times  per 
day. 

5.  How  often  is  this  process  updated?  Same  as  No.4. 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  The 

SK  manually  fills  out  this  form  for  archival  purposes. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information 
is  unclassified  but  sensitive.  The  volume  of  traffic  will  change  fi-om  day  to 
day. 

8.  What  is  the  source  of  information  for  this  process?  Parts  catalogues  and  a 
variety  of  United  States  Coast  Guard  regulations  govern  the  proper  ordering 
procedures. 

9.  What  is  the  current  status  of  the  process?  This  process  is  currently  not  on 
the  ESU  Intranet  and  is  manually  accomplished. 
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PARTS  ORDERING 


Process  7.0  Description  (Figure  6.10):  This  process  determines  the  proper  type 
of  procurement  for  the  requested  part  (Purchase  Request,  GBL,  VISA,  or  MELSTRIP), 
and  logs  details  into  a  log. 

1.  What  entities  does  this  process  effect?  Transport  Office,  Finance  Office 

(F). 

2.  How  many  users  does  this  process  have?  The  SK  is  the  sole  performer  of 
this  task,  but  it  is  done  for  every  member  of  the  command. 

3.  Who  is  the  primary  owner  of  this  process?  The  unit  SK. 

4.  How  often  is  this  process  used?  This  process  is  executed  several  times  per 
day. 

5.  How  often  is  this  process  updated?  Same  as  No.4. 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  This 
process  uses  multiple  updates  and  multiple  queries. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information 
is  unclassified  but  sensitive.  The  volume  of  traffic  will  change  fi’om  day  to 
day. 

8.  What  is  the  source  of  information  for  this  process?  A  variety  of  United 
States  Coast  Guard  regulations  govern  the  proper  ordering  procedures. 

9.  What  is  the  current  status  of  the  process?  This  process  is  currently  not  on 
the  ESU  Intranet  and  is  manually  accomplished. 
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PARTS  ORDERING 


Process  8.0  Description  (Figure  6.10):  This  process  occupies  25%  of  the  SK's 
time  and  verifies/monitors  the  status  of  all  open  parts  orders,  providing  feedback  to  the 
appropriate  entities. 

1.  What  entities  does  this  process  effect?  Transport  Office,  ESU  employees. 
Supplier 

2.  How  many  users  does  this  process  have?  The  SK  is  the  sole  performer  of 
these  tasks,  but  it  is  done  for  every  member  of  the  command  for  every  part 
that  is  ordered. 

3.  Who  is  the  primary  owner  of  this  process?  The  unit  SK. 

4.  How  often  is  this  process  used?  This  process  is  executed  several  times  per 
day. 

5.  How  often  is  this  process  updated?  Same  as  No.4. 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  This 
process  uses  multiple  updates  and  multiple  queries,  mainly  by  phone,  email, 
and  in  person. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information 
is  unclassified  but  sensitive.  The  volume  of  traffic  will  change  from  day  to 
day,  but  occupies  a  large  part  of  the  SK's  duties. 
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8.  What  is  the  source  of  information  for  this  process?  The  sources  of 
information  are  extremely  large,  including  shippers,  vendors,  sources  of 
supply,  and  other  military  sources. 

9.  What  is  the  current  status  of  the  process?  This  process  is  currently  not  on 
the  ESU  Intranet  and  is  manually  accomplished.  This  is  the  top  area  requested 
for  development  that  would  help  free  up  some  of  the  time  spent  updating 
personnel. 
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COTR  MODIFICATIONS 


Context  Level  Diagram  Description  (Figure  Appendix  B.l):  The  function  of 
the  ESU  COTR  as  it  pertains  to  contract  Modifications  is  to  act  as  an  intermediary 
between  Coast  guard  commands  (Operational  and  Maintenance)  and  the  additional 
services  requested  under  a  service  contract.  This  function  legally  protects  the 
government  and  ensures  the  contractor  is  paid  or  penalized  for  services  rendered  under 
the  scope  of  the  contract.  Since  only  the  Contracting  Officer  can  make  changes  to  the 
contract.  The  COTR  will  lobby  all  requests  and  make  recommendations  to  the 
Contracting  Officer  for  contract  modification. 

1.  Process  1.0  Description  (Figure  Appendix  B.2):  This  process  logs  all 
service  requests  for  services  outside  the  scope  of  the  existing  contract. 

2.  What  entities  does  this  process  effect?  USCG  Eleventh  District  operational 
units,  USCG  Support  Commands,  Contractors,  Contracting  Officer. 

3.  How  many  users  does  this  process  have?  The  ESU  COTR  staff  performs 
this  process  (less  than  ten). 

4.  Who  is  the  primary  owner  of  this  process?  The  COTR. 

5.  How  often  is  this  process  used?  This  process  is  executed  on  a  weekly  basis, 
and  sometimes  more  frequently. 

6.  How  often  is  this  process  updated?  Same  as  No.4. 

7.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  This 
process  uses  multiple  updates  and  multiple  queries.  Most  requests  come  in 
the  form  of  letters,  messages,  phone  calls,  and  email. 
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8.  What  type  of  information  does  this  process  use?  Most  of  this  information 
is  unclassified  but  sensitive.  The  volume  of  traffic  will  change  from  day  to 
day. 

9.  What  is  the  source  of  information  for  this  process?  The  operational  units 
are  responsible  for  reporting  operational  service  requirements,  as  their 
operational  needs  change. 

10.  What  is  the  current  status  of  this  process?  This  process  is  currently  not  in 
use  on  the  ESU  Intranet  and  is  manually  accomplished.  Updates  are  done  in 
numerous  ways  including  written  logs  and  word  processing.  All  of  this 
information  is  not  directly  available  and  is  a  complex  web  of  resources 
involving  information  controlled  by  outside  entities,  mainly  being  the 
Contracting  Officer  assigned  to  a  different  organization  than  the  ESU. 
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COTR  MODIFICATIONS 


Process  2.0  Description  (Figure  Appendix  B.2):  This  process  logs  all  service 
requests  for  services  outside  the  scope  of  the  existing  contract. 

1.  What  entities  does  this  process  effect?  USCG  Eleventh  District  operational 
units,  USCG  Support  Commands,  Contractors,  Contracting  Officer. 

2.  How  many  users  does  this  process  have?  The  ESU  maintenance  personnel 
perform  this  process. 

3.  Who  is  the  primary  owner  of  this  process?  The  COTR. 

4.  How  often  is  this  process  used?  This  process  is  executed  on  a  weekly  basis, 
and  sometimes  more  frequently. 

5.  How  often  is  this  process  updated?  Same  as  No.4 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  This 
process  uses  multiple  updates  and  multiple  queries. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information 
is  unclassified  but  sensitive.  The  volume  of  traffic  will  change  from  day  to 
day. 

8.  What  is  the  source  of  information  for  this  process?  The  COTR  will 
determine  if  a  need  exists  for  immediate  service  request  and  whether  it  should 
be  forwarded  as  a  request  for  permanent  contract  modification. 
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SHORE  SECTION  (CASREPS) 


Context  Level  Diagram  Description  (Figure  Appendix  B.3):  The  function  of 
the  Shore  Section  Chief  in  regards  to  CASREP  response  is  to  quickly  resolve  the 
problem.  This  can  be  done  by  using  Coast  Guard  members  who  work  directly  for  him,  or 
with  other  ESU  branches  to  gain  contract  assistance. 

Process  1.0  Description  (Figure  Appendix  B.4):  This  process  logs  all  submitted 
CASREPS  Avith  the  AOR  of  the  Shore  Section  Chief  for  archival  purpose. 

1.  What  entities  does  this  process  effect?  ESU  branch  personnel  within  the 
AOR  of  the  Shore  Section  Chief  (i.e.  they  work  for  him). 

2.  How  many  users  does  this  process  have?  All  ESU  Shore  Section 
employees. 

3.  Who  is  the  primary  owner  of  this  process?  The  Shore  Section  Chief 

4.  How  often  is  this  process  used?  This  process  is  executed  several  times  per 
day. 

5.  How  often  is  this  process  updated?  Same  as  No.4. 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  This 
process  uses  multiple  updates  and  multiple  queries.  Most  requests  come  in 
the  form  of  email  and  phone  calls. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information 
is  unclassified  but  sensitive.  The  volume  of  traffic  will  change  from  day  to 
day. 
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8.  What  is  the  source  of  information  for  this  process?  The  ESU  Shore 
Section  member  performing  the  service  desk  duty  function  for  that  day 
(service  desk  duty  revolves  on  a  weekly  basis). 

9.  What  is  the  current  status  of  the  process?  This  process  is  currently  not  on 
the  ESU  Intranet  and  is  manually  accomplished.  Updates  are  done  in 
numerous  ways  including  written  logs,  forms,  and  self-made  databases.  All  of 
this  information  is  available,  but  will  be  difficult  to  pinpoint  without  a 
prototype  design  for  Intranet  use. 


154 


SHORE  SECTION  (CASREPS) 


Process  2.0  Description  (Figure  Appendix  B.4):  This  process  determines  the 
priority  of  response  and  actions  to  be  taken  for  a  given  CASREP. 

1 .  What  entities  does  this  process  effect?  Indirectly  the  unit  with  the  problem. 

2.  How  many  users  does  this  process  have?  The  Shore  Section  Chief  is  the 
primary  user  of  this  process,  although  his  crew  often  reviews  it  for  work 
details. 

3.  Who  is  the  primary  owner  of  this  process?  The  Shore  Section  Chief 

4.  How  often  is  this  process  used?  This  process  is  executed  several  times  per 
day. 

5.  How  often  is  this  process  updated?  Same  as  No.4. 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  This 
process  uses  multiple  updates  and  multiple  queries. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information 
is  unclassified  but  sensitive.  The  volume  of  traffic  will  change  fi'om  day  to 
day. 

8.  What  is  the  source  of  information  for  this  process?  The  input  from  the 
source  of  the  CASREP  that  is  stored  in  a  service  log  by  a  service  desk 
employee.  The  priority  is  determined  by  information  known  to  the  Shore 
Section  Chief  that  is  not  documented  anywhere  (i.e.  importance  of  outage 
relative  to  other  outages). 
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9.  What  is  the  current  status  of  the  process?  This  process  is  currently  not  on 
the  ESU  Intranet  and  is  manually/mentally  accomplished. 
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SHORE  SECTION  (CASREPS> 


Process  3.0  Description  (Figure  Appendix  B.4);  This  process  monitors  all  open 
CASREPs  and  revises  priorities  as  needed. 

1.  What  entities  does  this  process  effect?  Indirectly  the  ESU  employees  and 
unit  with  the  problem. 

2.  How  many  users  does  this  process  have?  The  Shore  Section  Chief  is  the 
primary  user  of  this  process,  although  his  crew  often  reviews  it  for  work 
details. 

3.  Who  is  the  primary  owner  of  this  process?  The  Shore  Section  Chief 

4.  How  often  is  this  process  used?  This  process  is  executed  daily. 

5.  How  often  is  this  process  updated?  Same  as  No.4. 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  This 
process  uses  multiple  updates  and  multiple  queries. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information 
is  unclassified  but  sensitive.  The  volume  of  traffic  will  change  fi'om  day  to 
day. 

8.  What  is  the  source  of  information  for  this  process?  The  ESU  service  desk 
receives  requests  for  changes  and  updates  the  CASREPs  Storage  Log.  The 
Shore  Section  Chief  only  reviews  the  CASREP  Storage  Log  to  monitor  status. 
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9.  What  is  the  current  status  of  the  process?  This  process  is  currently  not  on 
the  ESU  Intranet  and  is  manually  accomplished.  A  self  made  database  is 
used. 
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SHORE  SECTION  (CASREPS) 


Process  4.0  Description  (Figure  Appendix  B.4):  This  process  determines  what 
t5^e  of  action  should  be  accomplished  to  resolve  the  casualty. 

1.  What  entities  does  this  process  effect?  ESU  COTR,  Eleventh  District  Unit 
with  CASREP. 

2.  How  many  users  does  this  process  have?  The  Shore  Section  employees 
perform  this  task  for  every  CASREP  that  is  submitted  for  repair. 

3.  Who  is  the  primary  owner  of  this  process?  The  Shore  Section  Chief 

4.  How  often  is  this  process  used?  This  process  is  executed  several  times  a 
day. 

5.  How  often  is  this  process  updated?  Same  as  No.4. 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  This 
process  uses  multiple  updates  and  multiple  queries. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information 
is  unclassified  but  sensitive.  The  volume  of  traffic  will  change  fi’om  day  to 
day. 

8.  What  is  the  source  of  information  for  this  process?  The  priority 
established  by  the  Shore  Section  Chief  and  current  funding  and  parts 
constraints. 

9.  What  is  the  current  status  of  the  process?  This  process  is  currently  not  on 
the  ESU  Intranet  and  is  mentally  accomplished  by  the  responding  technicians. 
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SHORE  SECTION  fCASREPS^ 


Process  5.0  Description  (Figure  Appendix  B.4):  This  process  performs  an 
archival  of  technical  information  to  attempt  to  provide  some  source  of  a  knowledge  base 
for  technicians. 

1.  What  entities  does  this  process  effect?  Indirectly,  all  entities  that  are 
supported  by  the  ESU. 

2.  How  many  users  does  this  process  have?  All  members  of  the  Shore  Section 
as  well  as  the  COTR. 

3.  Who  is  the  primary  owner  of  this  process?  The  Shore  Section  Chief 

4.  How  often  is  this  process  used?  This  process  is  executed  daily. 

5.  How  often  is  this  process  updated?  Same  as  No.4. 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  This 
process  uses  multiple  updates  and  multiple  queries. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information 
is  unclassified  but  sensitive.  The  volume  of  traffic  will  change  from  day  to 
day. 

8.  What  is  the  source  of  information  for  this  process?  Technicians. 

9.  What  is  the  current  status  of  the  process?  This  process  is  currently  not  on 
the  ESU  Intranet  and  is  manually  accomplished. 
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SHORE  SECTION  (CASREPS^ 


Process  6.0  Description  (Figure  Appendix  B.4):  This  process  determines  which 
parts  are  required  for  order. 

1.  What  entities  do^  this  process  effect?  None  directly. 

2.  How  many  users  does  this  process  have?  All  ESU  Shore  Section 
employees. 

3.  Who  is  the  primary  owner  of  this  process?  The  Shore  Section  Chief 

4.  How  often  is  this  process  used?  This  process  is  executed  daily. 

5.  How  often  is  this  process  updated?  Same  as  No.4 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  Forms 
and  technical  publications. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information 
is  unclassified  but  sensitive.  The  volume  of  traffic  will  change  from  day  to 
day. 

8.  What  is  the  source  of  information  for  this  process?  Parts  catalogues  and  a 
variety  of  Coast  Guard  regulations  govern  the  proper  ordering  procedures. 

9.  What  is  the  current  status  of  the  process?  This  process  is  currently  not  on 
the  ESU  Intranet  and  is  manually  accomplished. 
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SHORE  SECTION  (CASREPS^ 


Process  7.0  Description  (Figure  Appendix  B.4):  This  process  determines 
funding  requirements  to  resolve  a  CASREP  and  request  funding  as  they  are  needed. 

1 .  What  entities  does  this  process  effect?  The  unit  with  the  CASREP,  the  ESU 
SK,andtheESUXO. 

2.  How  many  users  does  this  process  have?  All  ESU  Shore  Section 
employees. 

3.  Who  is  the  primary  owner  of  this  process?  The  Shore  Section  Chief. 

4.  How  often  is  this  process  used?  This  process  is  executed  daily. 

5.  How  often  is  this  process  updated?  Same  as  No.4 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  This 
process  is  manually  performed  with  email  being  the  prime  source  of 
communications. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information 
is  unclassified  but  sensitive.  The  volume  of  traffic  will  change  jBrom  day  to 
day. 

8.  What  is  the  source  of  information  for  this  process?  A  variety  of  Coast 
Guard  regulations  govern  the  proper  ordering  procedures  and  funding 
guidelines. 

9.  What  is  the  current  status  of  the  process?  This  process  is  currently  not  on 
the  ESU  Intranet  and  is  manually  accomplished. 
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SHORE  SECTION  (CASREPS^ 


Process  8.0  Description  (Figure  Appendix  B.4):  This  process  identifies 
alternate  sources  of  test  equipment  needed  to  resolve  CASREPs  when  otherwise  not 
available. 

1.  What  entities  does  this  process  effect?  Transport  Office,  ESU  SK. 

2.  How  many  users  does  this  process  have?  All  Shore  Section  employees. 

3.  Who  is  the  primary  owner  of  this  process?  The  Shore  Section  Chief 

4.  How  often  is  this  process  used?  This  process  is  executed  weekly. 

5.  How  often  is  this  process  updated?  Same  as  No.4 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  This 
process  uses  multiple  updates  and  multiple  queries. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information 
is  unclassified  but  sensitive. 

8.  What  is  the  source  of  information  for  this  process?  The  sources  of 
information  are  extremely  large,  including  shippers,  vendors,  sources  of 
supply,  and  other  military  sources. 

9.  What  is  the  current  status  of  the  process?  This  process  is  currently  not  on 
the  ESU  Intranet  and  is  manually  accomplished. 
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COTRCASREP 


Context  Level  Diagram  Description  (Figure  Appendix  B.5):  The  function  of 
the  ESU  COTR  as  it  pertains  to  CASREP  response  and  service  requests  is  to  act  as  an 
intermediary  between  Coast  Guard  commands  (operational  and  maintenance)  and  the 
contractor  chosen  to  perform  certain  contracted  duties.  This  function  legally  protects  the 
government  and  ensures  the  contractor  is  paid  or  penalized  for  services  rendered  under 
the  scope  of  the  contract. 

Process  1.0  Description  (Figure  Appendix  B.6):  This  process  decides  whether  a 
request  for  maintenance  falls  under  the  contract  for  contractor  resolution  or  under  Coast 
Guard  maintenance  responsibility.  The  selected  source  of  maintenance  is  then  told  to 
perform  a  function  to  resolve  the  maintenance  casualty.  Feedback  amongst  entities  is 
exchanged  for  updating  purposes.  For  some  functions  the  contract  will  have  primary 
responsibility  with  Coast  Guard  military  members  acting  as  secondary  response  source  if 
the  contractor  is  unable  to  respond.  The  opposite  applies  to  areas  involving  the  Coast 
guard  as  the  primary  maintenance  source,  where  payment  for  extraneous  contractor 
services  is  paid  under  the  guidelines  of  the  contract.  All  information  is  archived  in  a  data 
store  for  monthly  review  to  determine  modifications  required  for  contractor  payments. 

1.  What  entities  does  this  process  effect?  USCG  Eleventh  District  operational 
units,  USCG  support  commands,  the  contractor. 

2.  How  many  users  does  this  process  have?  The  ESU  COTR  staff  performs 
this  process  (less  than  ten). 


164 


3.  Who  is  the  primary  owner  of  this  process?  COTR. 

4.  How  often  is  this  process  used?  This  process  is  executed  on  a  daily  basis, 
sometimes  more  frequently.  As  the  status  of  electronic  repair  changes,  the 
members  will  report  that  information  to  the  process. 

5.  How  often  is  this  process  updated?  Same  as  No.4 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  This 
process  uses  multiple  updates  and  multiple  queries. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information 
is  unclassified  but  sensitive.  The  volume  of  traffic  will  change  from  day  to 
day. 

8.  What  is  the  source  of  information  for  this  process?  The  operational  units 
are  responsible  for  reporting  equipment  casualties  and  operational  conditions 
as  it  changes.  The  Coast  Guard  maintenance  and  contractor  staffs  report 
repair  efforts  and  response  capabilities.  The  maintenance  contract  is  used  to 
determine  response  guidelines. 

9.  What  is  the  current  status  of  the  process?  This  process  is  currently  not  on 
the  ESU  Intranet  and  is  manually  accomplished.  Updates  are  done  in 
numerous  ways  including  written  logs,  word  processing,  spreadsheets,  and 
some  databases.  All  of  the  information  is  not  directly  available  and  is  a 
complex  web  of  resources. 
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COTR  CASREP 


Process  2.0  Description  (Figure  Appendix  B.6);  This  process  allocates  Coast 
Guard  maintenance  personnel  with  the  ESU  to  act  as  a  secondary  response  team  to 
contracted  services  as  required  to  meet  operational  needs. 

1.  What  entities  does  this  process  effect?  USCG  Eleventh  District  operational 
units,  USCG  support  commands,  the  contractor. 

2.  How  many  users  does  this  process  have?  The  ESU  maintenance  personnel 
perform  this  process. 

3.  Who  is  the  primaiy  owner  of  this  process?  COTR. 

4.  How  often  is  this  process  used?  This  process  is  executed  on  a  daily  basis, 
sometimes  more  frequently.  As  the  status  of  electronic  repair  changes,  the 
members  will  report  that  information  to  the  process. 

5.  How  often  is  this  process  updated?  Same  as  No.4 

6.  What  is  the  mode  of  use  for  this  process  by  the  entities  that  use  it?  This 
process  uses  multiple  updates  and  multiple  queries. 

7.  What  type  of  information  does  this  process  use?  Most  of  this  information 
is  unclassified  but  sensitive.  The  volume  of  traffic  will  change  from  day  to 
day. 

8.  What  is  the  source  of  information  for  this  process?  The  COTR  will 
determine  if  a  need  exists  for  a  secondary  response  service  request. 
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9.  What  is  the  current  status  of  the  process?  This  process  is  currently  not  on 
the  ESU  Intranet  and  is  manually  accomplished.  Updates  are  done  in 
numerous  ways  including  written  logs,  word  processing,  spreadsheets,  and 
some  databases.  Phones  are  mainly  used  to  disseminate  information. 
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APPENDIX  D  DATABASE  FORMS 


Si  BOL  _Status_Log_lnpul_Form  :  Form 


; ;;  ■■;o- 

Date  of  Thi^ 


YovVe  entered  Bill  Of  Lading  Status  Ij^date  fium.  If  yon  have 
^  infiixmation  te  addte  the  Usi^  oxif  youneed  to  modii^  the  status 
this  is  the  place  to  do  it  lliis  infeiniationwillhe  nsedto 
'-.axchive  status  infozmation  and  identify'  those  items  xe^'uixing 
viqidates  (so  he  sure  yon  put  in  the  date3> 


/  New  Status  of  Part 


Ithis  is  a  test 


./Name  of  Persw^ ; 

■  Performina  Ttiis  ilpd^e 


iiAMI  Sherri  Johns 


.  I  parts  affi^ 

I  .af  ttedestmatiph7"^ 

1/  r“  l^esl 


The  entire  history  of  this  item  may 
be  included  here,  be  sure  and 
scroll  through  the  list  to  see  them 
all.  Select  'New  Update'  to  add  to 


Figure  D.l  -  Bill  Of  Ladiug  Status  Log 


^  VisaNumb UpdateForm  :  Form 

m 

Eriter  or  rnodi^the  cornmands  ciJnrreriL  .. 

If  Isa  JIccoufit  Numbers.  Iliis  iMill  update 

Bvailable  choices  in  the  database  for  futu 

IftSB  orders.  .  ,  . 

Unit  Vi«»  Murnfaer  i  2::Hli 

JS  S3  O' 

ISM  RR  I 

.  rBwsBftwBwtS  : ' '  .  piffirtiffffB-  -  1 

"  ' . •  “  - 

Figure  D.2  -  Visa  Number  Update  Form 
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Figure  D.3  -  Purchase  Request  Visa  Order  Form 


ProgramElement lnpul Form  :  Form 


TouVe  entered  Aft  PiosiamneiHoeiitinpvilbiin. 

!;  coaimand  has  n  new  fondxns  ttcconnl  rede  te  add  te  ^ 
'youneedto  mikdi^tee  cidhj^^  ihas  Is  Ike  place  te  do  it 
^^Xhis  intennatten  wiU  he  nsed  in  several  DataBase  pnll  down 


{ This  form  shoiiid  only  be  filled  out 
by  the  unit^  Storekeeper;  ^  ■ 


IteitName: 


;  Program  OamaMt  Code:  '  thiii  Pnmdxag  L«£r 

i30/0/5A  '  ;  iMLCPm  ^  ■ 


M 


’Sawei .  .  tlw  1  ‘  %Detetet 


Figure  D.4  -  Program  Element  Input  form 
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Figure  D.5  SURF  Status  Log  Input  Form 


Figure  D.6  -  Unit  Cost  Center  Update  Form 
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Figure  D.7  -  SURF  Requisition  Log  Form 
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U.S.  GOVEPmiENT  BILL  OF  LADINO 


coacauLSJiiro. 


,  -Hi; 

S»»|  'Oetej 


>Opdo£e  " 
Log' 


Figure  D.8  -  Bill  Of  Lading  Form 
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APPENDIX  E  GLOSSARY  OF  TERMS 


AOR  (Area  of  Responsibility) 

CASE  Tools  (Computer-Aided  Software  Engineering) 

Software  tools  that  provide  automated  support  for  some  portion  of  the  systems 
development  process. 

CASREP  (Casualty  Report) 

This  is  a  form  that  is  submitted  to  U.S.  Coast  Guard  Maintenance  and  Logistic  units  to 
request  assistance  in  the  repair  of  faulty  equipment. 

CGI  (Common  Gateway  Interface) 

A  technology  used  to  build  dynamic  WWW  documents. 

COTR  (Contracting  Officers  Technical  Representative) 

COTS  (Commercial  Off  The  Shelf) 

COTS  is  intended  to  reduce  acquisition  cycle  time,  provide  access  to  state-of-the-art 
technology,  increase  competition,  and  provide  lower  costs  to  the  purchaser. 

DFD  (Data  Flow  Diagram) 

A  graphical  display  that  illustrates  business  processes  and  data  interfaces  from  a  data 
perspective. 
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ESU  (Electronic  Systems  Support  Unit) 

A  U.S.  Coast  Guard  facility  that  maintains  and  supports  all  facets  of  Coast  Guard 
electronic  equipment. 

ET  (Electronics  Technician) 

An  enlisted  rating  that  is  responsible  for  the  repair  and  maintenance  of  sophisticated 
electronics  equipment,  radio  receivers  and  transmitters,  radar,  navigation  equipment,  and 
computer  equipment. 

FDDI  (Fiber  Distributed  Data  Interface) 

A  LAN  technology  that  uses  fiber  optics  to  connect  computers  on  a  ring  technology 
(lOOMbits/s). 

FTP  (File  Transfer  Protocol) 

A  protocol  used  to  transfer  a  complete  file  fi’om  one  computer  to  another. 

Gopher 

A  software  that  provides  a  menu  for  accessing  Internet  resources. 

GUI  (Graphical  User  Interface) 

A  GUI  replaces  the  keyboard  commands  typical  of  old-fashioned  computers  with  point- 
and-click  buttons  and  menus. 
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HTML  (Hypertext  Mailcup  Language) 

The  code  which  is  used  to  create  and  display  information  on  the  WWW. 

HTTP  (Hypertext  Transfer  Protocol) 

The  protocol  used  to  transport  a  WWW  page  from  one  computer  to  another. 

IRC  (Internet  Relay  Chat) 

Facilitates  conversations  over  the  Internet  in  close  to  real  time. 

LAN  (Local  Area  Network) 

A  network  of  computers  that  transmits  data  along  a  single  shared  medium  in  a  small 
geographical  area  (i.e.  a  single  office  building  or  college  campus). 

MAU  (Media  Access  Unit) 

It  is  a  piece  of  equipment  that  adapts  or  formats  a  signal  for  transmittal  over  a 
communication  medium,  (i.e.  an  optical  transmitter),  which  accepts  an  electrical  signal  at 
its  input  port  and  converts  it  to  an  optical  signal  accessible  at  its  output  port. 

MIME  (Multipurpose  Internet  Mail  Extensions) 

A  mechanism  that  allows  nontext  data  to  be  sent  in  a  standard  email  message. 
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MLCLANT  (Maintenance  &  Logistics  Command  Atlantic) 

The  Coast  Guard  Maintenance  &  Logistics  Command  Atlantic  supports  Atlantic  Area 
operational  readiness  by  ensuring  that  Coast  Guard  vessels  and  shore  activities  are  fully 
capable  of  meeting  their  assigned  missions.  To  accomplish  this,  MLCLAhJT  provides  a 
broad  range  of  engineering,  personnel,  health  and  safety,  financial  management,  and  legal 
program  support. 

MLCPAC  (Maintenance  &  Logistics  Command  Pacific) 

The  Coast  Guard  Maintenance  &  Logistics  Command  Pacific  supports  Pacific  Area 
operational  readiness  by  ensuring  that  Coast  Guard  vessels  and  shore  activities  are  fully 
capable  of  meeting  their  assigned  missions.  To  accomplish  this,  MLCPAC  provides  a 
broad  range  of  engineering,  personnel,  health  and  safety,  financial  management,  and  legal 
program  support. 

SK  (Storekeeper) 

An  enlisted  rating  responsible  for  providing  and  accounting  for  the  constant  stream  of 
supplies,  clothing,  commissary  items  and  spare. 

TAD  (Temporary  Additional  Duty) 

TCP/IP  (Transmission  Control  Protocol/Internet  Protocol) 
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The  collection  of  transport  and  application  protocols  used  to  communicate  on  the  Internet 
and  other  networks. 

Telnet 

Allows  a  user  to  log  on  from  a  remote  computer. 

TT  (Telephone  Technician)  An  enlisted  rating  responsible  for  the  installation  and 
maintenance  of  many  types  of  telecommunications  equipment.  The  office  that  the 
technician  is  assigned  to  is  often  referred  to  as  the  TT  shop. 

URL  (Uniform  Resource  Locator) 

An  address  or  location  of  a  site  to  be  viewed  on  the  WWW. 

WAN  (Wide  Area  Network) 

A  network  of  computers  that  transmits  data  along  a  single  shared  medium  in  a  large 
geographical  area  (i.e.  can  span  multiple  cities). 

WWW  (World  Wide  Web) 

Computers  which  are  linked  and  which  provide  hyperlinks  to  Internet  resources 
worldwide. 
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